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