[Fedora-packaging] Re: Mail voting on kmdl adoption

[Axel Thimm]

On Mon, Aug 14, 2006 at 01:19:32PM -0400, Jesse Keating wrote:
> On Friday 11 August 2006 06:58, Axel Thimm wrote:
> > I suggest to vote through email about replacing the current kernel
> > scheme with the kmdl or similar scheme.
> 
> Perhaps I'm dumb, but after reading your wiki page I'm still not seeing where 
> the current scheme really falls over.  We have kmod packages treated like 
> kernel packages in that they are install rather than upgrade.  This is the 
> same way that the kernel is handled, and if people do silly things with the 
> rpm command line they can break their kernel just as easily as they can break 
> their kernel modules.

No, the issue is that kernel modules packages are neither to be
"coinstalled", nor to be "upgraded" if the package entity is not
disambiguated w/ uname-r-in-name

I've give such an exmaple before, try writing down an rpm command for
the following situation:

Installed:

kernel-a
module-2-for-a

kernel-b
module-1-for-b

Now try to install module-2-for-b. For kmdls it's just rpm -U. For
kmods it's impossible, you need to coinstall with module-2-for-a but
upgrade module-1-for-b.

That's why every depsolver suddenly needs a plugin to do anything at
all with kmods. The plugin needs to take this awkward situation in
account and undo things that yum considered sane to do (but yum was
only following rpm logic).

But the argument goes on that once you pull in a package "by mistake"
you cannot undo it unless it is trivial e.g. has no further package
depedencies like requires/obsoletes/conflict. These cascade further
changes in yum's dependency resolver and undoing them in a plugin
effectivly lead to redesigning yum in the plugin.

Currently the plugin assumes that is not the case, which is the case
with wireless/v4l/gfs/cluster/firmware support etc. So the plugin will
fail in these cases.

And any plugin for any other depsolver will fail the same and rpm
doesn't have plugins. The net result is a half-working yum, borken
rpm, broken smart etc.

In comtrast if the scheme respects rpm rules like the kmdl scheme does
you don't need to undo yum's work, just add the coinstall support. It
turns out that the plugin for kmdls was less than half the current
plugin for kmods which performs less and is still broken as outlined
above.

> We have this handling in yum, which is the basis of every depsolver
> we support in Fedora / Red Hat.  Yum is used by pup, puplet, pirut,
> and anaconda.  All of these make use of the special casing we have
> in Yum and handle kmods correctly by installing rather than
> upgrading them.

Thanks for the list. This means all of them are currently broken as
outlined. And all of them can be fixed by following basic rpm rules
like the kmdls do. The key point here is uname-r-in-name.

> If other depsolvers don't, well that's really too bad and its up to
> those depsolvers to handle the packages correctly like they (should)
> handle kernel packages correctly.

I agree, if rpm and yum/pup/etc *could* deal with it, but they don't.

> So, I guess I'm being dumb, and I need it spelled out in big foam
> letters as I'm just not getting it, and thus I can't vote on it.

Is the example above & argumentation clear? If yes, and the wiki is
not please suggest where to inject an example or soem more working in
the wiki.
-- 
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/20060814/cbe79c3b/attachment.bin