On Thu, 2007-10-18 at 23:58 +0200, Michael Schwendt wrote: > On Thu, 18 Oct 2007 13:32:07 -0700, Rick Stevens wrote: > > > > Yum reports that "_after_ installing the updates, the needed libraries > > > would be missing". > > > > Really? That's interesting. Didn't know that before. The error > > message it spits out is sure-as-heck misleading then. I read it as > > "I can't update because thus-and-so _is_ broken" rather than "I can't > > update because the update _would_ break thus-and-so." > > And so do many other users. > > Just notice that the other case can occur, too. As in "I can't install > foo because bar cannot be found anywhere" [neither in the installed > rpms nor in the enabled repositories]. > > It's just not what has happened in your case. ;) > In your case, an update removes/replaces files still needed by other > packages (which need updates themselves to adapt to the new > library dependencies). > > There are multiple sets of packages to consider: > > 1. The packages that fill your file system as covered in your local > RPM database. Files, which don't belong into any RPM packages, are > irrelevant (they are not looked at when resolving dependencies, > and they are overwritten without a warning). > > 2. Additional packages that may replace (i.e. update/upgrade/obsolete) > packages, which are available in the local RPM db already prior > to running Yum. > > 3. 1+2 (!) That is the set 1 modified with all updates from set 2, > which may also take away stuff that was available before. > > Yum's primary interest is in 3. The state your RPM db will be in after > installing the new packages. It tests whether it can apply the complete > set of RPM db changes from the packages to be installed. It refuses > to install anything that would end up with unresolved dependencies. > > Even if you have /usr/lib/libfoo.so.1 in package "libfoo" prior to > running Yum, a newer libfoo in the repository, which contains only > /usr/lib/libfoo.so.2, can replace the older libfoo and hide it from > Yum's scope. Any package, which still requires the old libfoo.so.1, > regardless of whether it's installed already or chosen from the > repository as an additional package to be installed, would break and > would cause Yum to report the problem as an unresolved dependency. > > I think Yum+RPM don't care whether an update removes a file that is > still needed. It doesn't matter. The result is the same. A set of RPM > DB changes can't be applied -- with a different upgrade path, you > could install the openexr update first and fail to install the old kde > pkgs afterwards as long as they sit in the repo with their dependency > on old libs. One could add a trouble-shooting handler to examine the > unresolved deps and try to find out what's wrong (e.g. point out that > the needed files are available before selecting update packages). But > that goes into the area of what the Smart package manager tries to > achieve, I think. Like "so, the needed files are in OpenEXR-libs > version X, there is an update to OpenEXR-libs version Y, and it no > longer contains the needed files, so exclude it and try again"). Most > likely that can result in other "funny" issues. And it still won't > help when something simply is not available anywhere. ;o) Yup, been down that road many, MANY times before. I can wait for a new OpenEXR-libs release, I suppose. As I said, this machine is an experimental hamster. In fact, its hostname is "labrat". ---------------------------------------------------------------------- - Rick Stevens, Principal Engineer rstevens@xxxxxxxxxxxx - - CDN Systems, Internap, Inc. http://www.internap.com - - - - We have enough youth, how about a fountain of SMART? - ---------------------------------------------------------------------- -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
