[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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-2.6.25.11-97.fc9.i686 = 173.14.09-5.lvn9 for package: kmod-nvidia
--> Running transaction check
---> Package kmod-nvidia-2.6.25.11-97.fc9.i686.i686 0:173.14.09-5.lvn9 set to be updated
--> Processing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 for package: kmod-nvidia-2.6.25.11-97.fc9.i686
--> Finished Dependency Resolution
kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 from livna has depsolving problems
  --> Missing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 is needed by
package kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 (livna)
Error: Missing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 is needed by
package kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 (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 =

Comments?

CU
knurd


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]