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
Attachment:
pgpRgsP8UG2rM.pgp
Description: PGP signature
