[Fedora-packaging] Re: kmod support - a diary of workarounds

[Axel Thimm]

Added to http://fedoraproject.org/wiki/AxelThimm/kmdls, search for
pandora's box.

On Tue, Aug 15, 2006 at 02:22:28AM +0200, Axel Thimm wrote:
> 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://lists.fedoraproject.org/pipermail/packaging/attachments/20060815/14a43ae2/attachment.bin