[Fedora-packaging] get further rid of uname -r in the kmod stuff and solve the remaining kmod problem

Jack Neely jjneely at ncsu.edu
Mon Aug 14 20:11:11 UTC 2006


On Mon, Aug 14, 2006 at 08:47:18PM +0200, Thorsten Leemhuis wrote:
> 
> 
> Jesse Keating schrieb:
> > On Monday 14 August 2006 14:06, Thorsten Leemhuis wrote:
> >> Yum will install:
> >>  kmod-foo-1.3.2.6.17-1.2171_FC5
> >> *and remove*
> >>  kmod-foo-1.2.2.6.17-1.2157_FC5
> >>  kmod-foo-1.2.2.6.17-1.2171_FC5
> >> in the same transaction because the module location of
> >> kmod-foo-1.2.2.6.17-1.2171_FC5 and kmod-foo-1.3.2.6.17-1.2171_FC5 would
> >> conflict. *This remove is the problem Axel complains about.*
> > I could see it removing kmod-foo-1.2.2.6.17-1.2171_FC5, but why does it also 
> > remove kmod-foo-1.2.2.6.17-1.2157_FC5?  Wouldn't that be in a different 
> > module tree?
> 
> Well, normally it's a "install transaction" but when there is a
> potential file conflict it's changed to a "upgrade transaction" afaik --
> and that will remove the old kmod as well because both old kmods have
> the same packagename.

This is not correct.  The current implentation will install the new
module and add an erase transaction element for the old module requiring
the same kernel.  

> 
> >> == Proposed solution ==
> >>
> >> Install the kernel-module to
> >>
> >> /lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko
> >>
> >> and remove the
> >>
> >> "Requires: kernel<?kernel-flavour>-<?kernel-version>
> >>
> >> Details:
> >>
> >> We avoid the file conflicts noted in "Problem" above due to the
> >> "VERSION-RELEASE" in the path. So yum will always install the module and
> >> there won't be any conflicts.
> >>
> >> But how will the kernel find the module there? "/sbin/weak-modules", the
> >> script from the kabi stuff can create links to the proper places. It
> >> does this already for modules installed in the proper place and kernels
> >> that have the compatible kabi. It would be needed to adjust some
> >> pathnames in the script, but that shouldn't be to hard.
> >>
> >> And why remove the Requires? Well, with the kabi stuff it might happen
> >> (not that often in Fedora, but on RHEL often) that a module runs fine on
> >> a newer kernel. We wouldn't have to build a new module in that case.
> >> *But* this requires would fire back because the kmod will get removed by
> >> the depsolver when the kernel is was build for gets uninstalled.
> >> Therefor it needs to be removed.
> > 
> > Also, with the kabi stuff, the Requires should get done automatically to an 
> > ABI version.  If the next kernel has an ABI change, and you rebuild the 
> > module, thats cool, it picks up the new ABI in the automatic Requires.  No 
> > manual intervention.
> 
> That would solve the problem nicely.
> 
> > I would _really_ like to get JCM involved in this discussion, especially on 
> > the proper place to drop these modules so that a respin for one kernel won't 
> > remove modules from an older kernel.
> 
> +1
> 
> CU

Generally, kabi sucks less, so +1

Right now I use the Requires: kernel-i686 = 2.6.14-1.1776_FC4 to figure
out what kernel we match, but that's easy to fix.

Jack

> thl
> 
> /me going to bed now soon
> 
> --
> Fedora-packaging mailing list
> Fedora-packaging at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-packaging

-- 
Jack Neely <jjneely at ncsu.edu>
Campus Linux Services Project Lead
Information Technology Division, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89




More information about the Fedora-packaging mailing list