RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories

Thorsten Leemhuis fedora at leemhuis.info
Sat Aug 2 12:21:30 UTC 2008

Hi all!

About one or two times a month a lot of people run into decency problems 
like this:

> $ sudo yum update
> [...]
> Resolving Dependencies
> --> Running transaction check
> ---> Package kmod-nvidia.i686 0:173.14.09-5.lvn9 set to be updated
> --> Processing Dependency: kmod-nvidia- = 173.14.09-5.lvn9 for package: kmod-nvidia
> --> Running transaction check
> ---> Package kmod-nvidia- 0:173.14.09-5.lvn9 set to be updated
> --> Processing Dependency: kernel-uname-r = for package: kmod-nvidia-
> --> Finished Dependency Resolution
> kmod-nvidia- from livna has depsolving problems
>   --> Missing Dependency: kernel-uname-r = is needed by
> package kmod-nvidia- (livna)
> Error: Missing Dependency: kernel-uname-r = is needed by
> package kmod-nvidia- (livna)

I'd like to find a solution to solve this problem (which is *not* 
specific to kernel modules/kmods and imho not really Livna's fault), as 
it seems to annoy users (and developers and mailing list subscribers, as 
those receive bug reports about this kind of problem nearly each time) a 
lot. The problem itself is not easy (I try to explain it below) and I'm 
not sure what's the best way to fix it -- hence this RFC.

= Short problem description =

Livna (which soon will be obsoleted by RPM Fusion) is shipping quite a 
bunch of add-on packages for Fedora packages. Most if not all of those 
add-on packages only work for a specific version of the software they 
enhance; thus the add-on packages from Livna have a strict dependency on 
the Fedora package they were build for. That leads to trouble when the 
Fedora package and its add-on package get updated, as there is no single 
point in time for Livna to ship the add-on package as update without 
causing trouble for users: Yum might try to install the updated add-on 
package before the Fedora mirror yum chose offers the updated Fedora 
package (like in the example above) or vice versa.

= Long problem description =

There are several add-on packages in Livna (soon: RPM Fusion) that have 
a hard dep on a specific Fedora package, as the Livna package was build 
specifically for this Fedora package. Among those packages are all 
kernel-module packages (kmods), but there are a lot of other add-on 
packages with a hard dependency on a specific Fedora package -- 
audacious-plugins-freeworld, k3b-extras-freeworld or 
xine-lib-extras-freeworld (those in Livna still carry the old nonfree 
postfix instead of the new term freeworld) are some of them.

When Fedora releases a new audacious, k3b, kernel or xine-lib we in 
Livna try to ship a updated version of the add-on package in a 
just-in-time matter -- e.g. when the new Fedora packages hits the repo 
and get announced on the package-announce list we try our best to push 
the updated add-on package (which we normally try to prepare in advance) 
immediately. Thus often the newly add-on packages are in the repo just 
10 or 30 minutes after the updated Fedora package was pushed.

This indirectly leads to trouble for the users. Livna doesn't have that 
many mirrors and yum on most systems fetches repodata and packages 
straight from the master repo -- thus yum sees the updated add-on 
package quickly and tries to install it. That fails quite often in the 
first 24 hours after the updated Fedora package was pushed, as yum most 
of the time retrieves repodata and packages from Fedora mirrors all over 
the world -- but those mirrors often have not retrieved the updated 
Fedora package yet. Yum's metadata-caching or temporary inactive mirros 
that were not checked by mirrormanager yet can make things worse.

Note that sometimes the situation might be the other way around as well 
-- depending on the Livna mirror yum chose it might happen that yum 
tries to install the updated Fedora package before it sees the updated 
add-on package. That often leads to dependency issues in yum as well 
(for non-kernel-module packages), as the Livna package the user has 
installed on his system strictly requires  the locally installed Fedora 
package that yum tries to be update. That's why "just wait a bit with 
the push for the updated Livna package" is no option here either.

Site note: all this might become a bigger problem in RPM Fusion in the 
future, when things in the nonfree have a hard dep on a package in the 
free repo (which can lead to similar problems in case yum updates the 
repodata for the nonfree repo, but not for the free repo). But I suspect 
it should not happen that often.

= RFC =

I'm unsure what's the best way to fix or work around this problem.

  * yum is the central piece of software in this game, thus it's easy to 
say "it needs to be fixed in yum; it needs to be taught to do a second 
look at the right place to find what's needed"; I'm a bit unsure myself 
if that's a good idea and suspect that skvidal doesn't like the idea to 
much either.

  * Livna/RPM Fusion could ship the updated Fedora packages in Livna/RPM 
Fusion repos together with the add-on packages; hard to get right, a bit 
ugly and I assume some people will dislike this idea. It'll get worse in 
RPM Fusion due to the split in free and nonfree repos -- kernels would 
need to be shipped in both repos to avoid similar problem :-/ I also 
fear that shipping nonfree kernel modules and the GPLed kernels in one 
repo might some people yell "license violation"

  * your suggestion here!

= EOF =



More information about the fedora-devel-list mailing list