On Wed, Aug 16, 2006 at 08:37:42PM +0200, Thorsten Leemhuis wrote:
> Axel, could you please take a look at this? Did I miss anything (I
> surely did)? I tried to concentrate on the technical details.
BTW this has nothing to do with the one-specfile approach but
nonetheless:
> * the buildsys must queue the rebuild of a kmdl srpm multiple times to
> get modules for all kernel flavours build in the kmdl case -- the kmods
> scheme can build all in one step. The variants and the kernel-version
> are currently hardcoded in the kmod standard because the Extras buildsys
> doesn't support passing the variants and the kernel version to rpmbuild
> call yet. Axel says that the kmod scheme is not "kernel
> {version,flavor} agnostic" due to this hardcoding. But this hardcoding
> currently allow us to build the kmods without other changes in the
> buildsys; kmdls can't get build without special support in the buildsys
> due to the needed "rebuild one srpm multiple times"
Bundeling many flavours in one build is bad, hardcoded or not. Having
4 dozens of kmdls around my belt I know that some kmdls don't build at
all on some flavours, the xen family currently displaying this quite
nicely, about 30-40% of kmdls are not buildable on them. When a
flavour fails to build it is either so by design, so nothing can be
done, or the kmdl can be fixed on package-level or upstream, or the
kernel can be fixed. Therefore you don't want the specfile to dictate
which flavours to build for, you want it to get this information from
the buildsystem (or not at all, the information about the flavour is
not even needed in kmdl schemes ...)
Also flavours may come and go within a distribution's life cycle. For
example a few weeks ago "xen" was added to FC5 along "xen0". No need
to touch specfile/src.rpm/userland in the kmdl scheme to add
supportfor the newcomer. For example the sole representant of kmods in
FE is em8300. Where is his "xen" flavour?
And don't forget custom kernel packages and support for them. I forgot
to mention this: ATrpms has contributed swsups2 kernels for FC4 and
FC5. By having the specfile/src.rpm kernel and flavour agnostic *and*
unbundled I can use the same specfile/src.rpm/userland for these
extras kernels/flavours, too. CCRMA has a set of their own kernels,
too.
So true kernel/flavour agnosticism and non-bundling of builds is a
true blessing.
Now about the buildsystem: My home-brewn buildsys has about 20 lines
of code to support multiple builds of the kmdl src.rpm, I don't expect
extending FC's and FE's buildsystem to be rocket science (BTW I did
study physics, so I'm good at rocket science ;) and I offered to put
my man hours into this (unless it get's all burned up before ...)
It's better to extend the buildsystem than to have hardcoded kernels &
flavours in all kmdl specfiles/src.rpm, have to unneccessarily rebuild
src.rpm, be forced to split subpackages into twin src.rpms and the
like. These are all unneccessary hacks, let's attack the real problem,
extending the buildsystem.
> * the kmod standard has the disadvantage that there are multiple srpms
> (e.g. one for kernel 2157 and one for kernel 2174). But this way we make
> sure that the
This mail looks unfinished.
--
Axel.Thimm at ATrpms.net
Attachment:
pgpK6DKPuZUAr.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
