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