[Fedora-packaging] Re: fedorakmod.py unfixable

[Axel Thimm]

On Tue, Aug 15, 2006 at 01:45:47PM -0400, Jack Neely wrote:
> On Tue, Aug 15, 2006 at 01:32:20PM +0200, Axel Thimm wrote:
> > Hi Jack,
> > 
> > On Sat, Aug 12, 2006 at 05:33:10PM +0200, Axel Thimm wrote:
> > > can you please answer on the statement below that wrt fedorakmod.py
> > > plugin if the wrongly tagged kernel module packages pull in other
> > > packages through dependencies you're hosed up?
> > 
> > 
> > > Please make a statement about that as this demonstrates that the
> > > plugin has unfixable flaws - which is neither yum's not the plugin's
> > > fault, it is just the mirroring of allowing an rpm-incompatible
> > > kernel module scheme.
> > > 
> > > I hope the correctness and maintenance issues here will persuade the
> > > last kmdl opponent. :)
> > 
> > I moved the issues to http://fedoraproject.org/wiki/AxelThimm/kmdls
> > 
> > Please check the raised issues and make a statement. The
> > kmod+yum+anyplugin setup just cannot work and it's the best for the
> > packaging folks to hear that from a third person, too. Thanks.
> 
> Axel,
> 
> I apologize for not making your requested statement earlier.  I hope
> this email proves to be acceptable.
> 
> I have read your Wiki article and I find several points that I do not
> agree with.  I will focus on one of these points here.  You state, in 
> bold text, "[kmdl] doesn't have any design bugs."  In fact, Seth, 
> Jesse, Thorsten, myself and others have pointed out multiple times flaws 
> in the kmdl kernel module packaging scheme.  Some of these flaws equally 
> affect both kmod and kmdl.

Please show me the *flaws*! The kmdl scheme perfectly blends into rpm
semantics.

> Having read your numerous posts to this list regarding kmdl, the wiki
> article you have authored, and your Yum plugin to support kmdl I see a
> common theme.  You are unwilling to admit that your scheme may not be
> absolutely perfect and are unwilling to work with others to compromise.
> In fact, Thorsten attempted to compromise again with you this morning
> and you immediately refused.

That's wrong. I myself had stated often enough that I don't like
uname-r-in-name. It is not "perfect" it is a neccessity given the
current packaging limitations.

And how exactly does the kmdl plugin tell you that I'm unwilling to
admit anything at all?

> The last two emails that you have sent in this thread addressed to me
> take this one step farther.  You have requested that I make a statement
> regarding issues you have with the workings of the fedorakmod.py plugin.

Yes, please and the request stands.

> In and of itself, that is fine.  However, you also tell me in both
> emails what my statement is to be and in the first justify why I will
> say such a statement.  I find this attitude hostile and offensive.

Oh, no, please do make your statement on your behalf. You certainly
don't need patronizing.

> My statement is thus:  Many people have spent a large amount of time
> working with the kmod standard in developing the standard to this point
> and preparing FC6, FE6, and RHEL5 to make use of this standard.  The
> kmod standard represents a significant step forward in kernel module
> packaging compared to older methods that I and many others have used in
> the past.  The proposed kmdl scheme does not offer a significant
> improvement in design or practice compared to the kmod standard.  It is
> simply a different selection of pros and cons.

So where is the statement? You are talking abstractly about kmdls and
kmods and I wrote explicitely about where and how fedorakmod.py is
broken. I'd like a statement about the possibility of yum working
properly with kmod.

The thesis that is given in the wiki is

- that fedorakmod is currently broken,
- that any future attempt to fix it breaks it even more,
- that it is therefore unfixable with limited man power

That's where I'd like you to either stand up and say Axel's
halucinating or to concurr with the outlayed facts. That's far more
valuable than quoting "kmod standard represents a significant step
forward", we want technical facts, not a marketing blob :)

Please the request for making a statement about current and future yum
support of kmods still stands. If you admit it's broken people will
make easier a decision. If you prove it's not broken or if broken
fixable with few steps then it will also help people decide.
-- 
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/f6fe97bb/attachment.bin