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