Hi, > 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. Hm, I have not used such wording at all and your interpretation is very subjective. I refuse to be lumped in with the "we think axel is a troll"-crowd just because I state my opinion. Believe me, you'll know when I'm trolling :) > > > "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? Yes, that's a good example. Also, I don't really see what that has to do with what Red Hat should be doing. They ship four kernels, and whether they ship four seperate -devel packages or one -devel for all four has no bearing on whatever you can do for all the kernels you ship, does it ? > 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 ... "hot air" is a word I never use. > > 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? A user with a custom rpm just builds whatever he wants against it. He doesn't even need a -devel package we're discussing about right now. I think you're drawing away the real discussion with these arguments. > 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. Yes, that would be nice as a feature. It could still be done automagically whatever way is used however. You're talking about something different. > > 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. No, I mean that each person who provides custom kernels to others is expected to know about packaging. Otherwise he shouldn't be releasing ANY .rpm in the first place, let alone something as complex as a kernel one. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> resistance is low when I'm feeling bored what I thought was fun isn't fun anymore <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/
