Hi, On Sun, 2004-07-04 at 14:15, Axel Thimm wrote: > Hi, again, > > On Sun, Jul 04, 2004 at 01:13:59PM +0200, Thomas Vander Stichele wrote: > > > The idea is to have kernel module src.rpms with > > > > > > Requires: kernel-devel >= 2.6.0 > > > > > > and have the external build-system provide the matching rpms and > > > kernel modules against. > > > > The build system does not need to provide kernelsrcdir if the location > > where the build files are stored has a decent name. > > It does, because you may have installed several kernel headers for > different kernels, so you'd like to pass to the build process for > which kernels to build kernel modules. New kernels get added and old > ones removed, and the src.rpm & specfile is to be kept invariant over > time (unless other changes require patching etc.) You only need to provide the release define for what kernel you want to build for. if it contains smp it will build smp stuff, if the --target is i586 it will build i586. The spec file can be written that way and countless examples exist as well of this working. That doesn't mean that it cannot be useful to have such a define in some cases; it just means that it's not necessary by default. For regular users it's even less of an issue since a regular user just wants to rebuild a .src.rpm for himself, and will probably not build both i586 and i686. > > The spec file already has all the info to distinguish what type and arch > > to build for (up/smp and i586/i686), so just give sensible names to the > > path and it's solved. > > How does the specfile know, whether I want to build up/smp and > i586/i686 etc on my x86_64 smp build host that produces all kernel > modules archs and flavours for all supported distros? Like I said; --target and --define 'kernel 2.6.5-1.358' or 'kernel 2.6.5-1.358smp' works just fine. > You could use defaults, for the running kernel, or the installed > kernel(s), of course, but in general you would need that information > to be an external input to the build process. Yes, just not in the form of kernelsrcdir; what can be done automatically should be done automatically. And again - kernelsrcdir is the wrong name from the start. > Not sure I follow, my remark was wrt to a suggested mega-kernel-devel > package containing kernel development bits for the N Red Hat kernel > errata in one package, e.g. bundling the kernel headers for kernels > > 2.6.5-1.358 > 2.6.6-1.427 > 2.6.6-1.434 > 2.6.6-1.435 > 2.6.6-1.435.2.1 > 2.6.6-1.435.2.3 If the grouping had obvious gains (like share a whole bunch of files) that might make sense. I'd prefer the separate, one for each kernel release, but who knows, there are lots of factors in play. > Each new kernel errata would require updating of this package, which > may be fine for RH, but not for custom kernels that will be missing in > the above package (e.g. a 2.6.7-bk9 kernel). Why do you keep harping on this ? You cannot expect Red Hat to do something that works out of the box for all third party kernels. Why don't you just make sure you have a similar solution to whatever Red Hat does that works for your set of custom kernels ? It's not because Red Hat decides to lump a few together for *their* packages that it forces you and your custom kernels to be together. The reason I think the decision is unconstructive is just because of stuff like this - let's focus on getting people from Red Hat that have historically even been completely against the idea of external kernel module packaging overall, and let's move up the ladder to a common solution one step at a time. Ask for something that makes it possible what we as packagers need to do, not for one where most parties need to compromise beyond what they're willing to compromise on. This is btw not a troll, just to make sure. I respect your work and I respect the time you put into this; I'm just not convinced that whether or not a package gets split up makes any sort of difference to whether or not you or me can package kernel modules. Thomas
