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