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

Jesse Keating jkeating at redhat.com
Tue Aug 15 01:02:01 UTC 2006


On Monday 14 August 2006 20:35, Axel Thimm wrote:
> 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? :)

Absolutely not.  Userland is separate from the kernel module.  Forcing the 
userland crud to be rebuilt and reshipped and redownloaded each and every 
time the kernel is updated (or kabi changes) is ridiculous.  There is a big 
difference between a set of userland+kmod for each module set and a new 
package each and every time the kernel is updated.

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

Are you really going to versionize the entire userland?  Have a separate 
daemon for each possible module version?  How does THAT work at boot time?  
When your userland moves beyond what your kernel can handle (udev updates, 
etc..) perhaps its time to update your kernel.  If you can't, well then 
perhaps you shouldn't be using a distribution that moves quickly.  And if 
you're changing the userland that fast on a RHEL product, well then you're 
using it wrong and tough ditty.

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

Nope.  The infrastructure bits were only a small part of my concern.  Still 
a -1.

-- 
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/905c0327/attachment.sig>


More information about the Fedora-packaging mailing list