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

Axel Thimm Axel.Thimm at ATrpms.net
Tue Aug 15 00:35:02 UTC 2006


On Mon, Aug 14, 2006 at 02:31:41PM -0400, Jesse Keating wrote:
> Seems to me that we're really trying to beat around a deficiency in RPM.  

Yes, that's pinned down nicely by tibbs as making rpm
two-dimensional. But that's what we've got and it is not going to
change for a long time.

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

As outlined by Panu this is not the case. In fact the infrastructure
and maintenance is halfed as there is really only one name, not two
like it is today. The kmod standard need two bugzilla entries per
package, two owner entries, two cvs modules. kmdls only need one.

So may I take that as a vote in favour of a one-sepcfile design? :)

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

OK, suppose some kernel module scheme like kmod works against yum's
depsolving. Since yum adhears to rpm orderign and the kmod scheme
doesn't that's not difficult to achive.

Now the setup is such that yum will either install too many or to few
packages. Too few is good, you can always add to yum's transaction and
yum will compute the new dependencies. Too much is really bad, because
the pulled in packages will pull in more packages or push out others
(due to Requires/Obsoletes/Conflicts).

Let's get to an example:

ipw3945 version X (the exmaple is real, but don't have me lookup the
true versions please) requires ipw3945d Y (a userland daemon). ipw3945
X+1 requires ipw3945d Y+1. If yum "wrongly" tries to pull in ipw3945-X
this will have pulled in ipw3945d-Y. Undoing this in some plugin code
would only remove ipw3945-X, not ipw3945d-Y.

Further examples are ivtv/v4l2, ipw2*/ieee80211, ipw2*/firmware etc.

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

The packages are really distinct and have different functionality and
depednencies. You need both evrs in the total package filename. Moving
them to the rpm name turns to solve 95% of all issues. And the fears
on increased infrastructure are unbased, you even save some.

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

OK, is that still the case after having seen that infrastructure is
not bitten?
-- 
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://listman.redhat.com/archives/fedora-packaging/attachments/20060815/8aa3bd70/attachment.sig>


More information about the Fedora-packaging mailing list