[Fedora-packaging] kmod support - a diary of workarounds (was: get further rid of uname -r in the kmod stuff and solve the remaining kmod problem)

[Axel Thimm]

On Mon, Aug 14, 2006 at 07:57:17PM -0400, Jesse Keating wrote:
> On Monday 14 August 2006 16:11, Jack Neely wrote:
> > > Well, normally it's a "install transaction" but when there is a
> > > potential file conflict it's changed to a "upgrade transaction" afaik --
> > > and that will remove the old kmod as well because both old kmods have
> > > the same packagename.
> >
> > This is not correct.  The current implentation will install the new
> > module and add an erase transaction element for the old module requiring
> > the same kernel.  
> 
> Wait, stop the presses.
> 
> Isn't this the "root" of the problem that Axel is complaining about, that the 
> kmod version of doing things will cause old modules for old kernels to get 
> removed?  If this isn't the case, then why are we talking about replacing the 
> current standard?

The root of the problem is the 5 workaround steps I listed in another
mail.

a) You start with the kmod scheme (merging two evrs together ) and
   find out that this way you can only support exactly one kernel
b) It looks like kmods are like kernels, e.g. always coinstall, adding
   Provides: kernel-module support to yum to tag all such packages as
   coinstallable.
c) You find out that kmod are by design neither "upgrade", nor
   "coinstallable" class of packages. rpm/yum only know these two kind
   of packages. So now

   c1) yum installs only kernel modules for the latest module version
       and the latest kernel. No newer module version is installed for
       older kernels even if they are available in the repo. That's
       because yum only coinstalls *the* newest which is a merged evr
       scheme is moduleversion/kernelversion. yum cannot guess the two
       dimensional background of the problem since it only sees one
       common evr.

   c2) yum coinstalls kernel modules for the same kernels bailing out
       with file conflicts

d) no problem, we have workarounds for workarounds for workarounds [...]
   Why not undo the "damage" that bad yum inflicted on us for being
   rpm compatible. Let's detect those coinstalls-that-should-be-none
   and start removing package in the plugin.

Oops still not addressing the bug with yum + plugin not seeing kmods
for previous kernels anymore at all!

Where would we be if we wouldn't start adding more workarounds, so
let's take a look into the crystal ball

e) Jack persuades Seth to change the "kernel-module" yum-core
   behaviour from "kernel{,-flavour}" behaviour. The latter really
   wants yum to only see the latest version and coinstall it, but for
   the former we want yum to see them all and coinstall newer kernel
   modules for old kernels, too, e.g. trying to fix c1)

f) Now suddenly yum sees too much, it also sees kernel modules that
   have a newer one installed (which may happen even today see [1]),
   so we need to remove these from the ongoing transaction

g) It turned out that only some kernel modules are trivial enough to
   be removed on the fly in the transaction set. Many kernel modules
   have package dependencies that pull in or push out other
   packages. An old kernel module for instance "wrongly" selected for
   updating and later discarded by the plugin had pulled in
   incompatible firmware or it's older userland component.

   Now how to detect which package was pulled in or pushed out by the
   unwanted packages in the transaction set? Let's think of a hack and
   find a workaroung later, the alphabet is long enough.

Hm, the alternative scheme only needed 99 lines of python for full
unbroken yum support and no further yum-core manipulation?

Hm, ...

Hm, ...
-- 
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://listman.redhat.com/archives/fedora-packaging/attachments/20060815/8ec7a74a/attachment.sig>