On Fri, 2004-06-25 at 17:23 +0200, Arjan van de Ven wrote: > On Fri, 2004-06-25 at 16:32, Jack Neely wrote: > > > Several solutions have been floated on this list over the last few months. > > > The one I personally like most is the concept that the openafs rpm, that was > > > posted here the other week, uses. That solution has the quite big advantage > > > of allowing users of this approach to make your modules for *all* released > > > kernels in one go and in one package, and thus allowing the user to go back > > > to older kernels without having to worry about an additional extra package > > > needed for that. > > > Another person also had a script to build modules automated, but done in a > > > different way, so I would not call this an issue without solution at all. > > > > > > > No. Including kernel headers in every single package that builds an > > external module is *WRONG*. Not to mention the side effect of building, > > say, openafs modules for, how many kernel errata does FC1 have now? > > surely someone can package it fully separate? I would actually prefer to > build for all errata. There's only a dozen max or so per release... If we do kernel-devel and have it so that the paths don't conflict, then there's no reason someone can't just install all the kernel-devel's they want. Then it's already done with our packaging and doesn't require any massaging by third parties. Which is better, IMHO, as it gives less of a chance of people shooting themselves in the foot. And if it's broken out from the kernel package, then it's not going to make the distribution any more bloated really. > > I've talked with enough people and read enough emails and documentation > > to understand that there is a pretty excepted standard for packaging > > kernel modules. > > All the ones I've seen have problems with the "want to have multiple > kernels and be able to go back and forth without pain" case. > Oracle's OCFS does this similar (and auto-picks the right architecture > out of it's archives of built modules) and that Just Works(tm). Users > can go back and forth all they want, install older kernels, install > other architectures of older kernels.. it Just Works(tm). Providing kernel-devel like I proposed makes it easy to get this working and has the advantage of acting like I as a user would expect. And it seems like it would work from a "me as a packager" perspective as well. > > kernel-smp is merged into kernel > > well.... the problem here is that a significant number of x86 class > machines don't boot the smp kernel.... This is more a longer term "I'd love to get there" sort of thing... I doubt it can be done in the short term, but I could see it being possible eventually. Jeremy
