On Wed, Aug 16, 2006 at 11:44:56AM -0700, Toshio Kuratomi wrote: > On Wed, 2006-08-16 at 19:29 +0200, Axel Thimm wrote: > > o The 'only-last-kernel-supported' simply becomes > > 'only-last-kabi-supported'. For Fedora it's the same anyway. > > So you still have issues with > > - no (security) updates for old kernels (or kabis) > > Okay. I haven't seen anything to contradict this yet, only a conflict > over whether this is a problem or not. (If I'm wrong, somebody point me > to the archives or restate the rebuttal) > > Even if kmdls were accepted, are we planning on having the buildsystem > build for multiple kernels? > > > - old kernels/kabis can get their module nuked or effectively > > disabled. > > > How? > > Will not get overwritten (which is how I think the term "nuked" has been > used in this thread.) I answered to this on fedora-devel. I also added this to the wiki. But still let's give an example (versions are faked and simplified, I don't want to go hunting them, but the example is bitter real): ipw2200-1 requires userland package ipw2200-firmware-1 We have two kernels, "a" the old one, "b" the new one. So kmod would deliver something like ipw2200-kmod-1-a and ipw2200-kmod-1-b For the two kernels before the module upgrade. Now the following three packages hit the repo ipw2200-kmod-2-a and ipw2200-kmod-2-b ipw2200-firmware-2 And the kmods require the new firmware. In the kmdl scheme they would both get installed and the old ones uninstalled (same for the firmware). %post %postun would also perform the proper install/upgrade distinction (another thing kmods fail, you cannot know whether this is an upgrade of install in the specfile, but that's another story). yum + the current yum plugn support will only try to install/upgrade ipw2200-kmod-2-b and ipw2200-firmware-2, kernel "a" became invisible to the upgrade. But ipw2200-kmod-1-a has a hard dependency on ipw2200-firmware-1 which is just being upgraded to a new version. Therefore the only way out is to uninstall ipw2200-kmod-1-a. So you have your old kernel's kmdo nuked. > Effectively disabled: What leads you to that conclusion? If the dependency was (wrongly) not strict, then the kmod is not nuked, but does not work anymore due to the new firmware => effectively disabled. > > o Currently there is a file conflicst guard of not having different > > modules for the same kernel coinstalled. The disambiguation in the > > file path lifts this safety pin and suddenly we can end up with > > several different module versions for the same kernel!!! > But they are not being used. If we treat the kernel modules the same as > the kernel itself, then this is expected. No, you're fallen for the dual nature of kernel modules. They carry a kernel evr and need to be coinstallable wrt that, but they carry their own evr, too, which needs to be in upgrade-mode like all other packages. Any argument to not do so would propagate to all other packages, too (hey, what if ipw2200-2 is broken, I want a fallback to ipw2200-1 vs hey, what if openoffice-3.0.1 is borken, I want a fallback to openoffice-3.0.0). > > And please stop throwing new kernel modules schemes to me :=) > > The problem is we're here debating 1) Can kmods be saved and 2) if they > can't be saved, do we want kmdls to replace them verbatim? > > So as you throw problems at the new proposals, people are going to > update the proposals to try to fix those problems. In the end we'll all > agree that there is an actual problem that no amount of fixing can > actually solve, or we'll look at the two proposals and say this pile of > hacks is less appealing to me than this one for [insert arbitrary reason > here]. Agreed, but I expect some more homework being done before throwing it out. I usually spend more time in writing an analysis of those hourly proposals than it took the author to think about them. -- Axel.Thimm at ATrpms.net
Attachment:
pgp52NTTBaddT.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
