On Wed, Jun 23, 2004 at 09:42:37PM -0400, Jeremy Katz wrote:
On Wed, 2004-06-23 at 16:01 -0700, alan wrote:
> It is going to make life more difficult for those who need to modify their
> kernel for whatever reason.
The same argument could be made for every other package we ship.
> This does not appear to be a useful change. It makes it more difficult to
> get to the source code, not less.
>
> Why was this change made? It seems counter-productive to me.
It makes the kernel just like _every other package in the distribution_.
Well, how many packages are there with a config file which is a couple
of kB large?
There's no reason why building a custom kernel should be
considered to
be any different from building, eg, a custom glibc.
Not really, while glibc could be build with or without some features,
the kernel has miriads of configuration options. Looking at the
current practice, I'd say on each glibc custom build you will find 666
custom kernel builds.
http://www.google.com/search?q=%22custom+kernel%22 38.800
http://www.google.com/search?q=%22custom+glibc%22 109
The "it's always been that way" argument doesn't
really fly.
Especially since once you understand making the changes from within
the package, that's actually easier, more reproducible and makes
your life easier for maintaining the changes you want to make over
the long term (or even in working towards getting those changes
included in the upstream kernel source.
Raising an rpm barrier to the already convoluted kernel configuration
is not really helping non-experts.
The net effect will be that people in need of a custom kernel will get
one from
kernel.org, not use the patched & packaged one which needs a
can opener to get to.
Not to speak of us kernel module builder, who will find once again
another way to work with the kernel ... sigh ...
--
Axel.Thimm at
ATrpms.net