On Sun, Jul 04, 2004 at 01:43:48PM +0200, Thomas Vander Stichele wrote: > > > But that is exactly the point of discussion. A kernel-devel package > > should be per kernel version, arch and flavour, not a > > conglomerate. That way you both have less bloat and it is universal to > > be extended to arbitrary kernel, e.g. ones in future errata, custom > > kernels and so on. > > You have said this over and over but not provided any explanation on why > this is so. "should be" is your personal opinion. Thomas, I understand the thread is long and old by now, but this kind of statements are completly moot and only to be considered as heat-ups. I have given grounds to all the above in past and today's posts. I'd like to ask you to check the thread again, as this is the third (!) post from you having me presented as a hot-air mouthed troll. > "universal to be extended to arbitrary kernel": maybe you should give an > example, because I really don't understand what you're trying to say > here. OK, check my recent nvidia-graphics drivers that have been build out of the same src.rpm for the following 30 kernels: 2.4.20-35_39.rh7.3.at 20-35_39.rh7.3.atbigmem 20-35_39.rh7.3.atsmp 2.4.20-35_39.rh8.0.at 20-35_39.rh8.0.atbigmem 20-35_39.rh8.0.atsmp 2.4.20-35_39.rh9.at 20-35_39.rh9.atbigmem 20-35_39.rh9.atsmp 20-35.7 2.4.20-35.7bigmem 20-35.7smp 20-35.8 20-35.8bigmem 20-35.8smp 20-35.9 2.4.20-35.9bigmem 20-35.9smp 22-1.2197.nptl 22-1.2197.nptl_51.rhfc1.at 2.4.22-1.2197.nptl_51.rhfc1.atsmp 22-1.2197.nptlsmp 2.4.26-1.ll.rhfc1.ccrma 26-1.ll.rhfc1.ccrmasmp 2.6.6-1.427 2.4.2.6.6-1.427smp 2.6.6-1.435.2.3 2.6.6-1.435.2.3smp 2.4.2.6.7-1.456_4.rhfc2.at 2.6.7-1.456_4.rhfc2.atsmp It includes vendor (RH) kernels, ATrpms kernels, and even PlanetCCRMA kernels. These are all the common kernels packaged and deployed BTW. All this using a non-packaged version of the kernel-headers per kernel flavour/arch as descibed above. I'd call that "universal to be extended to arbitrary kernels", wouldn't you? And I'd also say the method has already proven in the field. There two dozen kernel module rpms successfuly deployed at ATrpms.net in the above manner resulting in several thousands (!!!) of binary kernel modules rpms. So, yes, it's quite more than hot air ... > I don't see how creating *four* rpms for four kernels as compared to > *one* devel rpm for four kernels is extra maintenance. Ehm, how will the user with his custom rpm be treated? Open the conglomerated rpm and add his own kernel? No, that's far from user-friendly. And the discussion of keeping things bundled is done in favour of the user, right? And don't forget, the suggestion of one kernel header package per kernel/flavour/arch is producing those _automatically_ while building the kernels themselves. There is nothing you need to _do_ to get them, e.g. no extra maintenance, while adding a new kernel header to the mega-kernel-header package is extra maintainance. > People releasing their custom kernel in the wild should take up > responsibility and provide the same mechanism as upstream does. You mean each _user_ who wants to have his custom kernel packaged and kernel modules build for it should become an rpm expert? Not really. -- Axel.Thimm at ATrpms.net
Attachment:
pgpRzg9A4c4KC.pgp
Description: PGP signature
