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
Attachment:
pgpSRdSxvGoR0.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging