On Mon, Jun 28, 2004 at 12:40:22PM +0200, Arjan van de Ven wrote: > actually it 100% is. kernel-devel, if it ever comes to a reasonable > thing, will be in *addition* to what is there right now not as > replacement. Maintaining two solutions for the same problem? It is per definition error-prone and predestined that one of them will deteriorate over time. > > Split the headers off the kernel rpms, you will be doing yourself, > > users and packagers a great favour. There are no advantages in either > > bundling all header files together, nor in bundling kernel and kernel > > header files. > > no splitting this off will hurt users. Maybe not packers but users it > does. How will this hurt users, can you explain? > I'm sorry but I have a really hard time taking packaging advice from > anyone who uses the current kernel-sourcecode method to build module > rpms. I am sorry you feel that way, and I can only verify that the kernel-source(code) package is flawed in this respect. But it is rectifyable and better than not having an rpm to depend on at all. And after all, we are trying to fix the current methods of kernel source/headers deployment, so hacking on your own package design won't help you. It was all you gave us, and we did our best in the given framework. And practice shows that it has worked, kernel modules are downloaded, installed and successfully used at a very great extent. You cannot ignore that, no matter how hard you try. ;) > > Just check a few kernel module rpms yourself to see the real problems > > in the dirt and not on the blueprints ;) > > I've looked at some and I have yet to find a single one that is packaged > remotely correctly. (if that is at all possible, something I'm not > entirely convinced of) It is, perhaps I'll find time to fix the kernel src.rpm over the weekend to demonstrate. Too bad it has close to zero chances of being adopted, judging from this thread. ... > > The demand profile is > > o kernel module rpm should be agnostic of location of kernel > > headers/source. This is passed with "--define"s to the src.rpm. > > this basically makes the point moot of where the kernel headers come > from. If you have to pass the location in the name of the exact > requires: is utterly irrelevant surely. No, no macros into BuildRequires, all you have is BuildRequires: kernel-headers >= 2.6.0 (In a previous main I had written Requires instead of BuildRequires). Of course you will use variable Requires in the resulting binary kernel module rpms to match the targeted kernel. > > o They should be independent of RH, ATrpms, other 3rd party repos, > > custom kernel rpms, e.g. one specfile/src.rpm for all. The choice is > > driven by the --define above > > ... and the --define can't give the exact package to require for the > headers? I don't believe that. No, because that would be dependency information embedded into the src.rpm, which is to be kept independent of the kernel. > > o header files/source may not overlap for different arch/flavour > > combination. > > I think you mean "it must be possible to get all headers for all > archs/flavors installed in parallel somehow". That is a quite less > restrictive requirement. Well, let's agree in that one to have something to agree with ... > Anyway I thank you for this list of requirements, as far as I can see > there's nothing in there that voids or blocks the kernel-devel mechanism > I proposed, in fact it strengthens it... OK, I am getting wierd off in trying to keep you from jumping off the cliff. Just do it and see for yourself. I now understand, why you need social experiments in rawhide. ... -- Axel.Thimm at ATrpms.net
Attachment:
pgpHKHDk78uQh.pgp
Description: PGP signature
