[Fedora-packaging] Re: Kernel Module Packaging Standard Teleconference

[Jon Masters]

On Thu, 2006-08-17 at 09:01 +0200, Axel Thimm wrote:

> The suggestion Thorsten is implying is that you should try under
> 
> /lib/modules/*/foo/1/1.2.3/2
> /lib/modules/*/foo/1/1.2.3/1
> /lib/modules/*/foo/1/1.2.2/1
> /lib/modules/*/foo/0/10/1
> 
> in that order for several coinstalled versions of foo *for the same
> kernel* (the folder names are epoch/version/release), and you would
> have to use rpmvercmp to compare the folder names.
> 
> That's a package problem that is being pushed to the wrong domain. For
> the same kernel (or kabi) the module should have one version
> installed. Otherwise the argument of having multiple versions of
> anything, not only kernel modules applies.

That's a problem. Some people genuinely want to have more than one
version of a module installed - I think in the longer run that this
would be a good thing to be able to support, though I much prefer using
modinfo meta-data to solve it rather than the file location.

We should compel people to use module versions properly in their source
code IMO since it's deliberately designed to support what we need from
it - and it's trivial enough to warn on build/load of non-kernel
provided modules that they don't have good version info inside.

> > With kabi checking enabled (if you package with kABI deps) then you get
> > for free the compatibility links automatically added/removed on module
> > install/remove so older kernels can use a more recent kmod. You will be
> > able to ultimately instruct module-init-tools to always use the version
> > of a module in weak-updates over the built-in kernel and thereby get a
> > given module to always be available to all compatible installed kernels.
> 
> The relation is different between what you and Thorsten think. It's
> many kernel modules *for* the same kernel vs many kernel modules *from
> different* kernels/kabis.

*** The following is for explanatory purposes, not part of thread ***

Yeah. We're talking about different things here - I'm just trying to
clarify what I've done with the kABI stuff because I didn't really get
at this part of the problem before. Let's say this happens (this is more
of a RHEL-type problem but *not exclusively* so I mention it here):

* Fedora kernel provides module foo.
* Module is upgraded with kmod to bar with different compile options.

Now, if we upgrade the kernel then we might upgrade to a newer and more
improved module that happens also to make my root device unavailable
because it broke on hardware X. So in that case we want to supply a
depmod configuration file along with the kmod files that tells depmod to
*always* use the kmod rather than the built-in driver from a newer
kernel - i.e. override the weak-updates logic we're using which says
that newer kernels always contain better versions of the module.

This isn't the OO problem. OpenOffice doesn't run the risk of breaking
your hardware on upgrade and people don't usually want to be able to use
different builds of OO from many different locations. With external
drivers not provided in Core we are *specifically allowing* people to
have several different builds of the same driver in different RPMs.

*** end of off-topic bit ***

> If the newer pakcage is broken, downgrade to the previous is the
> typical solution, not coinstall all under the sun :)

Indeed. Though there's the complication that we'd ideally like to not
prevent the system from booting when it's been upgraded remotely. This
is not something that is addressed at the moment :-)

> > My personal opinion is that it's too late to change kmods drastically in
> > FC6.

> I agree, my suggestion is not to change, but to dump :)

Dude. We're on T2 right now. In 6 months, there'll be another Fedora and
during that time we have plenty of scope to look at this some more. IMHO
you haven't shown *compelling* evidence for kmods to be dropped in FC6
but instead have highlighted some issues to be looked at for FC7.

Jon.

-- 
Jon Masters                  Phone: +44 7776 131337
Red Hat UK, Ltd.             Email: jcm at redhat.com