[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

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

CFLAGS += -I/usr/src/kernel-headers-2.2/include

And not have to worry about all the revisions, or detecting anything

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 Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '

Reply to: