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 ...
Attachment:
pgphjF60fQ3kc.pgp
Description: PGP signature
