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