[Fedora-packaging] Re: kernel-module packaging discussing broken into pieces: One specfile approach vs. splitted spec file

[Thorsten Leemhuis]

Axel Thimm schrieb:
> 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 

As I said in my mail:

Note: There is a really big area where parts/ideas of one approach could
be moved over to the other and the other way around. [...]

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

I disagree.

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

Sure, but that *can* be filtered within kmod spec file if we want to. It 
it could also be done by the buildsys (that's what I'd prefer). In your 
case the buildsys would have to do it. So none of the two is really 
better then the other. Just a matter of taste.

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

You'd have to ask scop. Maybe it didn't build, don't know. But just as 
above: there is no difference between kmdls and kmods when the buildsys 
handles that. In the kmod case the buildsys can simply run

rpmbuild kmod-foo.src.rpm --define 'kversion 2.6.17-1.2145_FC5' --define 
'kvariants "" smp xen xen0 XenU bigsmp never_have_heard_of_flavor'

and it's build as long as never_have_heard_of_flavor exists -- no 
modifications to the specfile needed.

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

This works for kmod, too, as long as the custom kernel follows the FC 
kernel scheme exactly.

> So true kernel/flavour agnosticism and non-bundling of builds is a
> true blessing.

As I said: There is no real difference between kmods and kmdls here if 
the buildsys handles everything.

[...]

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

Yeap. It should end with:

But this way we make sure that the SRPMS listed by "rpm -qi" really is 
the source rpm that was used to build stuff. Some people wanted that, 
but that's no big deal.

CU
thl