This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 49064 - up2date bombs out when package on system is newer than package to update
up2date bombs out when package on system is newer than package to update
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: up2date (Show other bugs)
4.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Fanny Augustin
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-07-13 08:11 EDT by Graham Leggett
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-08-03 05:12:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Graham Leggett 2001-07-13 08:11:07 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.73 [en] (X11; I; Linux 2.4.6 ppc)

Description of problem:
When a system contains an RPM that has been updated manually to a package
that is more up to date than that offered by Redhat, the up2date program
bombs out completely before doing anything useful - rendering the entire
thing useless.

The correct behavior would be to download the "updated" package and not
install it, or to skip the package and move on to the next one flagging it
for manual intervention.


How reproducible:
Always

Steps to Reproduce:
- On a Redhat v6.2 system, upgrade the initscripts package to 5.83-1.
- Run up2date

	

Actual Results:  [root@samantha /root]# /usr/sbin/up2date -u --download

Retrieving list of all available packages...

Removing installed packages from list of updates...
########################################

Removing packages marked to skip from list...
########################################

Getting headers for available packages...
########################################

Removing packages with files marked to skip from list...
########################################

Getting headers for skipped packages...
########################################
The following Packages were marked to be skipped by your configuration:

Name                                    Version        Rel  Reason
-------------------------------------------------------------------------------
exim                                    3.22           6x   Config modified
kernel                                  2.2.19         6.2.7Pkg
name/pattern
kernel-headers                          2.2.19         6.2.7Pkg
name/pattern
kernel-pcmcia-cs                        2.2.19         6.2.7Pkg
name/pattern
kernel-utils                            2.2.19         6.2.7Pkg
name/pattern


Testing package set / solving RPM inter-dependencies...
########################################
RPM conflict error.  The message was:
Test install failed because of package conflicts:
package initscripts-5.83-1 (which is newer than initscripts-5.00-1) is
already installed



Expected Results:  up2date should have flagged the error, but continued to
the next package.


Additional info:

This bug renders Redhat Network useless to me. I have asked for a refund of
my subscription charges as a result.
Comment 1 Adrian Likins 2001-07-13 20:23:24 EDT
Hmm. I suspect what is happening is that the initscripts-5.83-1 you
installed  (where did this package come from btw?) is causing some
broken depencies (was the package installed with "--nodeps" or
"--force" ?). The system may appear to work correctly in this
case, but when rpm tries to install pacakges that have dependinces
on initscripts (several of the 6.2 updates do...), they can not
find whatever resource they need, so they attempt to upgrade both
of the packages involved in order to complete the transaction set. 

In this case, it looks like up2date attempt to "upgrade" initscripts
to the default one for 6.2, which cant replace the newer versioned
initscripts you have installed. This last part sounds like it
is probabaly a bug (up2date shouldnt of tried to update initscripts,
even if it meant leaving a incomplete transaction set with unresolved
deps). In either case the update will fail.

If you can provide more information about the initscripts-5.83-1 package,
and the args used to install it, I'd appreciate it. I assume the initscripts
package is the one from Red Hat Linux 7.1? 
Comment 2 Graham Leggett 2001-07-14 11:05:33 EDT
The problem is that up2date bombed out completely with a fatal error - when
clearly a dependancy problem with one package is not a fatal error.

What up2date should be doing is saying "I cannot install package XXX because
there is problem YYY" and then move onto the next package. Currently it's
behavior is "one package is not right, and I refuse to do anything else until
this is 'fixed'" which renders the entire up2date mechanism useless.

The initscripts package was manually updated to support other packages on the
machine.

It seems that the whole up2date mechanism only works on machines with a default
installation of Redhat. As soon as you make any changes to your configuration
(for example to make the machine do something useful) Redhat Network stops
working.
Comment 3 Adrian Likins 2001-07-16 13:41:07 EDT
up2date will fail if the packages you choose to upgrade can not
be upgraded successfully.  In this case, that package is initscripts,
which means just about any sizeable install set is going to fail
(a good chunk of the distro depends on initscripts, or packages with
deps on initscripts). Given a solveable dependcy chain, up2date should
be able to handle any upgrade path you throw at it. In this case, it
sounds like the chain isnt solveable (at least not while staying
in the realm of 6.2 packages, the path to completely solve this set
would involve essentially upgrading the box to 7.1+updates. cross
release package solving is currently not supported)

Moving to an incompatibale version of a core package causes all
sorts of problems in trying to get a complete installable transaction
set. It's not a problem that can be solved without at some point
deciding that some given dep is not important. There are no plans
to add the ability to ignores deps to up2date at this time. 

Adding the ability to modify a set of packages to install if
the deps fail may be added to the interactive gui client at some point.
Comment 4 Graham Leggett 2001-07-18 09:03:12 EDT
This isn't what I am seeing at all - the error message generated was:

RPM conflict error.  The message was:
 Test install failed because of package conflicts:
 package initscripts-5.83-1 (which is newer than initscripts-5.00-1) is
 already installed

up2date is complaining about the initscript package specifically - not any other
package.

It has nothing to to with solving the dependancies on other packages, because it
is possible to use up2date <packagename> and update each package manually - the
packages all install fine, and there are no dependancy problems as a result. The
problem only occurs when you use up2date -u and the Redhat Network to do this
automatically.

The problem is specifically with up2date - it cannot handle the case where it's
been asked to apply an update to a package that is more up-to-date on the
system.

This behaviour is default behaviour for RPM which makes sense where RPM is run
manually - I suspect that up2date is using RPM directly to try and update the
package, but it is not telling RPM _not_ to bomb out with a fatal error should
the installed package be more up to date than the update package.

What up2date should be doing is saying "problem with package install, trying
next package" - not "fatal error".
Comment 5 Graham Leggett 2001-08-02 21:24:21 EDT
Has any progress been made on this?
Comment 6 Adrian Likins 2001-08-02 21:58:57 EDT
up2date installs all the packages as a single transaction. If that
transaction fails, it reports the error and exists. 

In this case, it sounds like there are unresolved deps on initscripts, 
so it attempts to upgrade initscripts. It finds the latest one available
for that release, but is unable to install it because a newer version is
already installed. For whatever reason, that newer version is causing
unresolved depencies. ie, to solve the deps, it either needs to downgrade
the package, or pull in packages from 7.1, neither of which up2date is
designed to do.

 Something has an unresolved dep on initscripts. If you
install packages manually, you may not see this, because the package with
the dep on initscripts is not part of the transaction set. But with a 
full upgrade, it is part of the transaction set, and does raise the dep
error that causes up2date to try to upgrade initscripts. 

up2date will not attempt to upgrade a package that is the same version, or
a newer version of the latest package available from the up2date servers,
unless it has to solve dep errors. Or at least, I don't see anyway it can,
and havent been able to reproduce that kind of behaviour so far.

If you could send me a copy of your /var/lib/rpm/Packages  file as an
attachment, I can reconstruct your rpm db and see if I can duplicate the 
behaviour. 

Comment 7 Graham Leggett 2001-08-03 05:12:28 EDT
> up2date installs all the packages as a single transaction. If that
> transaction fails, it reports the error and exists. 

This is a design flaw. This means that if there is a problem with one package -
the system is not updatable from that point on at all. The system should update
all the packages it possibly can, reporting failures specifically on those
packages it can't.

> In this case, it sounds like there are unresolved deps on initscripts, 
> so it attempts to upgrade initscripts.

There is one package left to be upgraded - the kernel. All other packages were
updated one at a time with up2date <packagename> with no resulting dependancy
problems. According to rpmfind, this kernel depends on initscripts >= 3.94. The
version of initscripts installed on the system is initscripts-5.83-1. This
dependancy is therefore satisfied. up2date is trying to "upgrade" initscripts in
error.

I will attach the RPM database as you requested...
Comment 8 Josef Komenda 2002-10-30 18:00:59 EST
Looks like the RPM db never got attached, and no action in over a year. Closing

Note You need to log in before you can comment on or make changes to this bug.