Re: build depends on kernel-headers
On Sat, May 05, 2001 at 09:44:07PM +1000, Herbert Xu wrote:
> On Sat, May 05, 2001 at 10:27:53AM +0100, Philip Blundell wrote:
> >
> > Actually, I'm not even completely convinced that having them in the
> > kernel-image package name is particularly beneficial. But, even if we leave
> > that the way it is, I don't think it's impossible to arrange for kernel-headers
> > to be named differently.
>
> Kernel-image packages need to have version numbers encoded in them so that
> upgrades can happen smoothly. Kernel-headers need the version numbers as
> you may have multiple kernel-images packages in the archive.
>
> The thing is, kernel-headers should not be used at all unless you're
> compile glibc, or modules. Anything else will break.
False. That is the very thing I want to alleviate (people using kernel
headers from the libc6-dev package).
People should not be using them, but if they do, they should use a
kernel-headers package, and not rely on the headers in libc6-dev which
are different on all archs, and change almost every new glibc build. You
are never guaranteed to get the prefered kernel headers for your program
(be it a scsi level thing like cdrecord, or mount tools like
util-linux).
The point here is to make packages start moving to Build-Dep'ing on
kernel-headers-* packages. The question is, how to allow them to do that
easily.
IMO, we can use alternatives. And it should be fairly easy
update-alternatives --install /usr/src/kernel-headers-2.2 kernel-headers-2.2 \
/usr/src/kernel-headers-2.2.<rev> <rev>
Where "<rev>" would be something like "19" (as in 2.2.19). This way each
newer version would be prefered over the former. The only problem I see
are the -preX releases. Someone would have to suggest how to handle that
case since the priority field wont accept letters.
Also, I think that packages should Build-Depends on kernel-headers-X.X.
IMO, There is no reason to build-dep on anything more specific, and also
no reason to build-dep on just "kernel-headers" (IOW, maintainers should
test which kernel headers can be used). This way they can always just
do:
CFLAGS += -I/usr/src/kernel-headers-2.2/include
And not have to worry about all the revisions, or detecting anything
special.
Xu, can this alternative system be added to the kernel-headers package
scripts? Does anyone see a problem with this solution (that isn't
already a problem with the current usage of kernel headers in libc6-dev
that is)? Anyone got a solution for the -preX case, which would probably
make this method rock solid?
Ben
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: