No more kernel-source(code) ??? (was: rawhide report: 20040623 changes)
Arjan van de Ven
arjanv at redhat.com
Mon Jun 28 08:32:53 UTC 2004
On Mon, 2004-06-28 at 10:22, Axel Thimm wrote:
> > > In what way? What files would be missing?
> > the generated .mod.c and .mod.o files (for example jbd.mod.c and jbd.mod.o
> > for jbd.ko module) would be missing for example.
> OK, the kernel %install script could detect whether modversions have
> been selected in .config and package these files, too, then. Will be
> quite a bloat, but if there is no other way...
exactly, but it can only do that AFTER building the kernel. So the plan
of one grand unified kernel-devel for all architectures isn't a feasible
> > > packages on par with the kernel[-smp|-<other flavour>] packages, and
> > > have the latter have a symlinked /build/ to the former.
> > I do not want /build/ to become a symlink again.
> How will you solve the issues with
> a) same uname -r for different kernels (different archs)?
that's unrelated entirely.
> b) splitting kernel headers for the kernel?
I don't see splitting as a goal. Providing separate we can talk about,
but splitting I don't see as option; the current mechanism has too many
advantages for that.
> > > You don't want to shove all headers in one rpm, as this will again
> > > make it harder to build custon kernels with their custom
> > > kernel-headers/devel packages.
> > no it's not harder, they just provide their add-on kernel-devel package, so
> > your kernel series could have a kernel-axel-devel rpm ...
> No, it is ;)
> The idea is to have kernel module src.rpms with
> Requires: kernel-devel >= 2.6.0
and your kernel-axel-devel can't Provides: kernel-devel = <foo> ?
> You also want to provide users with a uniform way to build their own
> kernels and kernel-headers/devel packages, so you don't have much
> choice than to do it per kernel and not bundled.
I disagree with that conclusion. It's one simple script as the openafs
rpms and the other method posted here both have shown.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20040628/3e0c5935/attachment-0002.bin
More information about the devel