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

[Axel Thimm]

On Mon, Aug 14, 2006 at 09:02:01PM -0400, Jesse Keating wrote:
> 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.

Yes, I agree, so it's nice that this is not the case with kmdls :)

Just go over to ATrpms and have a look at the packages. You have many
misunderstandings on the kmdl proposal and maybe looking at real
packages may help. Testing them out with the kmdl plugin would be even
better.

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

No, the versions above are not kernel versions, you misinterpreted
them. The example is all within the same kernel, say 2.6.17-Z if you like.

> Have a separate daemon for each possible module version?

Again a misinterpretation. The daemon has nothing to do with the kmdl
scheme, it's part of the project. There is no daemon in the
design. But you asked for real life examples and that is one. Instead
of a daemon this might be the firmware packages etc, and no - the
kmdls scheme doesn't need firmwares per module, neither. :)

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

All in the wrong context, you made some wrong assumptions and ended in
a devastating picture of the kmdl scheme. I shudder myself from such a
vision. :)

> > > Thanks, I've heard enough to make up my mind.  -1 on the entire thing.
> Nope.  The infrastructure bits were only a small part of my concern.  Still 
> a -1.

You are misinterpreting my explanations beyond recognition, so perhaps
I should simply accept that. ;) If doubts come up, you know where to
find me.

It's 2 in favour 1 against for now. Still looking for 4 people which
will give their +1. :)
-- 
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/20060815/ac8bbd7f/attachment.bin