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. 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 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? > 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. > >[...] > > For a very small (but also very old) example see > > > > http://dl.atrpms.net/all/arc4.spec > > >From a quick glance: > > -> no proper debuginfo packages Where do you see that in the specfile? FWIW debuginfos are no problem at all for kmdls. > -> 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. Which is why the same specfile can be used unaltered for xenU/xen0/xen/PAE/kdump and whatever future kernel flavours may come up or even on RHEL flavours like hugemem. And it even works when the flavours change over the curse of time like "xen" suddenly appearing in FC5 alongside xen0/xenU. 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 :=) -- Axel.Thimm at ATrpms.net
Attachment:
pgpiBuHjWEM6H.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
