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