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
Attachment:
pgpNpSPX0N1JD.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
