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

[Axel Thimm]

On Wed, Aug 16, 2006 at 11:04:31PM +0100, Jon Masters wrote:
> > So adding evr semantics to module-init-tools? BTW where is the epoch
> > in your file path suggestion? ...
> > Gotcha! :)
> 
> I'm already adding a conf.d to m-i-t (but still toying with the exact
> implementation to be figured out over this week) so you can specify the
> priorities for individual /lib/modules directories. This is actually to
> solve another problem, which is that sometimes you might want to use
> kmods to override the built in kernel modules, sometimes not but you
> might also want to *explicitly* set behavior in the module RPM.
> 
> You could (a)buse this to override the ordering of modules if we
> switched to a new packaging system. Right now, the ordering of
> directories in our m-i-t is:
> 
> * Try /lib/modules/*/updates - if there, the admin did it.

Or any of 67 kmdls from ATrpms.

> * Try /lib/modules/*/extra - if there, it's in a current kmod.
> * Try /lib/modules/* - if in the kernel, cool.
> * Try /lib/modules/weak-updates - if there, /sbin/weak-modules did it
> when looking to find compatible modules on kmod remove/install.

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.

> 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 kabi solution tries to recycle kernel modules from foreign kernels
where possible as given by kabi metrics, it hs nothing to do with
kernel module upgrades within the same kernel (as going from
foo-1.2.2-1 to foo-1.2.3-1 in the example above). Using the kabi
mechanisms for that would be wrong. Just to make it clearer: These
pile of kernel modules would share the same kernel abi, e.g. their
value for recycling is the same, if foo-1.2.2-1 for kernel X can be
recycled, so can foo-1.2.3-1 for the same kernel, so why pick the old
package at all?

If the argument is because the newer package might be broken, then the
same applies to any other non-kernel related package and we're not
going to allow several coinstallations of gcc/glibc/openoffice etc and
have the PATH/linker decide on evr semantics.

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

> 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 :)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20060817/d4ebbb61/attachment.sig>