[Fedora-packaging] Kernel Module Packages

Jack Neely jjneely at pams.ncsu.edu
Thu Aug 18 21:35:34 UTC 2005

Well...that's one way to summon me...post my code all over the
internet.  :-)

The ideas and methods we had on the table a while back were...not always
inline with each other.  The information I had when I wrote that mess
was that a kernel module package was deemed a kernel module package by
having the %{name} kernel-module-<foo>.  Providing kernel-modules seemed
to have gotten lost.  Then I became frustrated because folks kept making
the specs more and more complex.  Way too complex for sane package
managers.  Mostly the ways to get the packages not to generate source
packages on each rebuild and crap.

Secondly, in the Yum world we decided to start doing some big changes
and I commited this bit.  Then we thought better and decided to release
2.4.0 and do the big changes in 2.5.x.  Hence, I should probably remove
that code from the 2.4.x series.

If we want kernel module packages to be successful they can't be that
complex for the packager.  Are there lots of special cases?  You bet.
Let the special cases be handled once in Yum code.  Let the other
special cases be handled once in Plague.  Otherwise, each packager will
do things ever so slightly different which leads to breakage.  Not to
mention how tired we will be of correcting and explaining.


On Thu, 2005-08-18 at 16:55 -0400, Jeff Spaleta wrote:
> On 8/18/05, Tom 'spot' Callaway <tcallawa at redhat.com> wrote:
> > We're doing this for user sanity as well, and to help differentiate
> > userspace packages from kernel-module packages. (Yum might be checking
> > for it as well, but I'm not the expert on that).
> Just FYI on my rawhide box, the current yum magic seems to be partly
> relying on packagename syntax and partly on provides syntax right now.
> Unless i've misread yum sniplet2 below.
> yum sniplet2 seems to say if the packagename starts with
> "kernel-module-" then handle it like a kernel module and check for an
> upgrade situation versus an install situation by looking at whether
> the required kernel version is installed already (see sniplet1).
> sniplet2 also says to check to see if the package is in the
> installonly list (see sniplet1).  For kernel modules to be in the
> installonly list by default they need to provide "kernel-modules"
> according to sniplet0
> from /usr/lib/python2.4/site-packages/yum/config.py
> <sniplet0/>
> ('installonlypkgs', ['kernel', 'kernel-bigmem',
>                                               'kernel-enterprise','kernel-smp',
>                                               'kernel-modules',
>                                               'kernel-debug',
> 'kernel-unsupported',
>                                               'kernel-source', 'kernel-devel']),
> </sniplet0>
> Anything providing "kernel-modules" will be treated as installonly by default.
> >From  /usr/lib/python2.4/site-packages/yum/depsolve.py  on my rawhide box
> <sniplet1/>
>  def allowedMultipleInstalls(self, po):
>         """takes a packageObject, returns 1 or 0 depending on if the package
>            should/can be installed multiple times with different vers
>            like kernels and kernel modules, for example"""
>         if po.name in self.conf.installonlypkgs:
>             return 1
>         provides = po.getProvidesNames()
>         if filter (lambda prov: prov in self.conf.installonlypkgs, provides):
>             return 1
>         return 0
> def handleKernelModule(self, txmbr):
>         """Figure out what special magic needs to be done to install/upgrade
>            this kernel module."""
>         def getKernelReqs(hdr):
>             kernels = ["kernel-%s" % a for a in rpmUtils.arch.arches.keys()]
>             reqs = []
>             names = hdr[rpm.RPMTAG_REQUIRENAME]
>             flags = hdr[rpm.RPMTAG_REQUIREFLAGS]
>             ver =   hdr[rpm.RPMTAG_REQUIREVERSION]
>             if names is not None:
>                 reqs = zip(names, flags, ver)
>             return filter(lambda r: r[0] in kernels, reqs)
>         kernelReqs = getKernelReqs(txmbr.po.returnLocalHeader())
>         instPkgs = self.rpmdb.returnTupleByKeyword(name=txmbr.po.name)
>         for pkg in instPkgs:
>             hdr = self.rpmdb.returnHeaderByTuple(pkg)[0]
>             instKernelReqs = getKernelReqs(hdr)
>             for r in kernelReqs:
>                 if r in instKernelReqs:
>                     # we know that an incoming kernel module requires the
>                     # same kernel as an already installed module of the
>                     # same name.  "Upgrade" this module instead of install
>                     po = packages.YumInstalledPackage(hdr)
>                     self.tsInfo.addErase(po)
>                     self.log(4, 'Removing kernel module %s upgraded to %s' %
>                              (po, txmbr.po))
>                     break
> </sniplet1>
> <sniplet2/>
> if txmbr.ts_state == 'u':
>                     if txmbr.po.name.startswith("kernel-module-"):
>                         self.handleKernelModule(txmbr)
>                     if self.allowedMultipleInstalls(txmbr.po):
>                         self.log(5, '%s converted to install' % (txmbr.po))
>                         txmbr.ts_state = 'i'
>                         txmbr.output_state = 'installing'
> </sniplet2>
> -jef
> --
> Fedora-packaging mailing list
> Fedora-packaging at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-packaging
Jack Neely <jjneely at ncsu.edu>
Realm Linux Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89

More information about the Fedora-packaging mailing list