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