On Mon, Jun 28, 2004 at 09:15:49AM +0200, Axel Thimm wrote:
On Sun, Jun 27, 2004 at 07:20:30PM +0200, Arjan van de Ven wrote:
>
> > The only problem with using a kernel-devel package is the same problem
> > the kernel binary suffers from right now, dealing with situations like
> > parallel installs of i586 and i686. The only potential solution to
> > this problem has been to have kernel-devel include build information
> > for ALL arches for the given kernel release. Several people have
> > brought this up, but I've seen very little to no discussion on the
> > potential downsides to piling in all the arches into one kernel-devel.
>
> well you first would need to show it's possible and future proof....
>
> right now we put the info in /lib/modules/../build *after* building that
> exact kernel, and there's a good reason for that: the kbuild system
> assumes a fully built tree. Now in the rpm we cheat and effectively
> remove the files we don't need. And *maybe* now that doesn't depend too
> much on the build results, but if you enable modversions for example it
> already does.
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.
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.
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 ...