[Fedora-packaging] Re: atrpms kernel modules

[Axel Thimm]

On Tue, Aug 08, 2006 at 07:52:20AM +0200, Thorsten Leemhuis wrote:
> >You only have three %if/%else/%endif constructs in a common
> >specfile saving quite a bit of redundant information and having a
> >proper common changelog - maintenance and package overview is much
> >better in a common specfile.
> 
> I don't think that's a real benefit.

Lower maintenance not a benefit?

> >I think some of the design problems of the current kernel module
> >scheme is due to allowing too much "external" pressure to get them
> >through. I don't think/remember early drafts to have done this
> >splitting of src.rpms just as I know the uname-r was removed due to
> >external requests. The kernel module scheme was finally accepted,
> >but at what price?
> 
> It was a compromise and I must say it works a lot better than the stuff 
> we had before (with uname-r in the name) and I'm quite satisfied with it.

I'm sorry, but you actively ignore the fact that was discussed over
and over again in this thread that this scheme is *broken at rpm
level*, dragging into the breakage all depsolvers which therefore
*require* patching/plugins all one-by-one to avoid severe problems
like nuking current working graphics drivers from the system. And you
know that this will never get fixed on rpm level.

How can you be satisfied with this situation, when you know it can all
be fixed? And not even know, but can see in practise. The kmdls are
there since several years.

> Okay. Looking closer. But that would also means you get a SRPM per 
> kernel variant afaics? That will waste a lot of space on the servers 

Yes, that would waste a lot of space. NO, THIS IS NOT THE CASE!!!

Please, Thorsten, it does look to me that you are desperately trying
to find reasons against kmdls. You're really pushing me to the edge.

The waste of space are the current src.rpm pairs that are needed in
your scheme. Twice the sources is redundant, a waste of space and
error prone. so if you agree on saving space let's go kmdls, they only
need half the space. ...

> >The easy maintenance of the kmdl scheme based specfiles and
> >buildsystems are the reason why ATrpms can offer that many kernel
> >modules for that many distributions/releases/flavour at a very timely
> >schedule after each kernel upgrade with only a fragment of one human
> >resource :=)
> 
> I still can't see it being much easier, sorry. Here and there it's a bit 
> easier, yes, but here and there it's a bit more complicated -> overall 
> it comes down to the same.

Sorry, we strongly disagree. What exactly is more complicated about
kmdls? The fact that

o plugins are not *required*, but a nice-to-have?
o these plugins are at most half the code that a plugin for the
  current scheme needs?
o works at rpm level?
o Only one src.rpm for everything cutting space and reducing
  maintenance

I can only see benfits with kmdls, and not nice-to-have stuff, but
required functionality that the current scheme cannot offer.

For God's sake *the current scheme is broken* and we're trying to patch
up yum with plugins to get back to rpm behaviour. And the patch/plugin
is still not complete, and the same is needed for other depsolvers and
still rpm CLI will be broken. Shouldn't that make all alarms sound?
That's far from "overall it comes down to the same".
-- 
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/20060808/9145a5b6/attachment.bin