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

[Jesse Keating]

On Monday 14 August 2006 14:16, Axel Thimm wrote:
> 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).

Seems to me that we're really trying to beat around a deficiency in RPM.  
Creating whole new packages for every single kernel release is insane.  New 
cvs modules, new bugzilla entries, new ownerships, etc, etc, etc..  Our 
entire infrastructure is based around the name of a package.  Changing that 
for every single kernel update, or special casing it in every system is just 
silly.  REALLY silly.  I will absolutely vote against it.

> 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.

I have read these two paragraphs 5 times, and I still don't understand what 
you are saying.  Examples work wonders.  I'm lost in hyperbole land.

> 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.

You're working around an issue in rpm by creating new packages all the time.  
That's not a solution, that's an ugly hack.

> > 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.

Or, instead of introducing the insanity of uname-r in name, we can put effort 
into adjusting rpm and yum to handle this sort of package situation 
correctly.

> > 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.

Thanks, I've heard enough to make up my mind.  -1 on the entire thing.

-- 
Jesse Keating
Release Engineer: Fedora
-------------- 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/20060814/82cf8bbd/attachment.sig>