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

[Axel Thimm]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20060816/b4d8dbe2/attachment.bin