[Fedora-packaging] Re: atrpms kernel modules

[Thorsten Leemhuis]

Axel Thimm schrieb:
> On Mon, Aug 07, 2006 at 06:19:51PM +0200, Thorsten Leemhuis wrote:
>> Axel Thimm schrieb:
>>> On Mon, Aug 07, 2006 at 10:19:19AM -0500, Tom 'spot' Callaway wrote:
>>>
>>> o one src.rpm for both userland and kernel module subpackages.
>> People disliked that when we created the current kmod standard because
>> either you build the userland stuff for i586 and i686 or you have to add
>> a lot of
>> %if foo
>> #build userland
>> %endif
>> %if bar
>> #build module
>> %endif
>> into the spec file.
> 
> It's better than to have two possibly divergent specs/src.rpms.

Debatable. When the kmod standard was developed people were in favor of 
a split.

I used the above scheme for round about two years (E.g. FC2, FC3 and 
FC4) and I prefer the two srpms solution now that I got used to it (I 
didn't like it in the beginning).

> Just
> imagine a cvs patch to apply to to both packages at once. 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.

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

>> People also wanted proper debuginfo packages. This means that you have
>> to create the debuginfo packages either manually or have to increase the
>> release each time you build for a new kernel.
> Proper debuginfo packages are produced at ATrpms - just not published
> due to lack of size.

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, technically all those SRPMS contain the same stuff, but there were 
people that want to find the corresponding SRPM by looking at 
%{SOURCERPM} -- that will fail if you don't upload all those SRPMS)

>>> [...]
>> -> has to be queued to the buildsys multiple time to build for UP, SMP,
>> Xen, ... (it at least looks this way? Or am I wrong?)
> 
> Yes, and that's actually a *feature* I forgot to add to the design
> principles:
> 
> o kmdls are completely kernel flavour agnostic.  There is no hardwiring
>   up/smp/xen anywhere.

That's also true for the current kmod stuff. We hardwire it currently 
for the buildsystem until it gains support for to pass the defines over. 
And new kernel flavour should in work without adjustments.

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

CU
thl