No more kernel-source(code) ??? (was: rawhide report: 20040623 changes)

[Jeremy Katz]

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