F8T3 yum update failures

[Michael Schwendt]

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)