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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
