Bug 134440 - inconsistent dependency resolution when updated dependency package drops needed library
inconsistent dependency resolution when updated dependency package drops need...
Product: Fedora
Classification: Fedora
Component: up2date (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bret McMillan
Fanny Augustin
Depends On:
  Show dependency treegraph
Reported: 2004-10-02 15:28 EDT by Alexandre Oliva
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-05 11:27:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2004-10-02 15:28:18 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)

Description of problem:
Consider that, after a fresh install, you attempt to install Livna's
vcdimager, that depends on libiso9660.so.0.  As it turns out,
Fedora.us's libcdio-0.69 offers this shared library, but libcdio-0.70
doesn't any more.  I suppose that's why both packages are still
available from the fedora.us repo for FC2.

Since vcdimager also depends on libcdio.so.0, up2date chooses the
newer version of libcdio first, and then, when it attempts to resolve
the libiso9660.so.0 dependency, it fails, because it never reconsiders

Unfortunately, up2date -i libcdio-0.69 (or even
libcdio-0.69-specificrelease) doesn't work, presumably because up2date
doesn't try to use 0.69 as the version number.  But when I run up2date
--get libcdio-0.69, it correctly downloads the rpm I want, obviously
without bringing in the needed dependencies to install this package.

up2date --solvedeps libiso9660.so.0 also fails.  libcdio-0.69-*.hdr
never make it to /var/spool/up2date; AFAICT up2date discards it early
as out-of-date.  A bad idea in this case.

Even after I manually install the package, after installing its
dependencies with up2date, up2date will *sometimes* decide that it
wants to update libcdio, and then fail because the library only
provided by the old version of the package isn't provided by any other
package any more.  It seems to happen more frequently when there are
lots of packages to update, e.g., after a daily rawhide push.  If I
--exclude=libcdio to get the other packages updated, it completes the
update and then it won't attempt to update libcdio again.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Make sure you don't have libcdio already installed
2.up2date -i vcdimager (have livna and fedora.us stable in up2date
3.up2date --solvedeps libiso9660.so.0
4.up2date -i libcdio-0.69
5.up2date -i libcddb
6.up2date --get libcdio-0.69
7.up2date -i vcdimager

Actual Results:  2 and 3 fail because up2date fails to consider the
older version of libcdio.

4 fails, possibly for the same reason, but possibly because up2date
fails to regard -0.69 as a version number.

5-7 work, but it could be far more cumbersome if libcdio was a package
with a large number of dependencies.

Expected Results:  It would be nice if 2 worked in these conditions
(older library package provides shared library that newer library
package doesn't, but that is still needed), but having working 3
and/or 4 might be good enough.

Additional info:

In case by the time you get to this the packages no longer trigger the
problem, here's a scenario that should be easy to create artificially:

package foo-1 provides foo1, package foo-2 doesn't
package bar requires foo1

Have the 3 packages in the same yum repository, and try to install bar.
Comment 1 John Thacker 2006-10-29 15:26:18 EST
up2date was replaced by pirut and put (package pirut) as of FC5.  Only FC5 and
FC6 are currently fully supported; FC3 and FC4 are supported for security fixes
only.  If this bug occurs in FC3 or FC4 and is a security bug, please change the
product to Fedora Extras and the version to match.  If you can verify that the
bug exists in RHEL as well, please change the product and version appropriately.

The codebase for pirut and pup is quite different, but if a similar bug exists
in pirut and pup in FC5 or FC6, please change the product to pirut and the
version appropriately and update the bug report.

We apologize that the bug was not fixed before now.  The status will be changed
to NEEDINFO, and if the bug is not updated with evidence that it is a security
bug or a bug that affects RHEL, it will be closed.
Comment 2 John Thacker 2006-11-05 11:27:21 EST
Closing per previous message.

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