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