F8T3 yum update failures

[Rick Stevens]

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 at internap.com -
- CDN Systems, Internap, Inc.                http://www.internap.com -
-                                                                    -
-         We have enough youth, how about a fountain of SMART?       -
----------------------------------------------------------------------