Re: build depends on kernel-headers
>>"Ben" == Ben Collins <firstname.lastname@example.org> writes:
Ben> False. That is the very thing I want to alleviate (people using kernel
Ben> headers from the libc6-dev package).
However, that is what 99% of the programs out there need to
do, since they really are not dependent on the specifics of kernel
structures, and we should discourage un needed dependency on kernel
Ben> People should not be using them, but if they do, they should use
Ben> a kernel-headers package, and not rely on the headers in
Ben> libc6-dev which are different on all archs, and change almost
Ben> every new glibc build. You are never guaranteed to get the
Ben> prefered kernel headers for your program (be it a scsi level
Ben> thing like cdrecord, or mount tools like util-linux).
Now, for the 1% or so of the packages that really are wedded
to kernel headers, that is correct. But then these packages should
not run on n a kernel version that they were compiled for. (HINT: if
your program can run on a kernel different from the one you compiled
for, the chances are that you do not need specific kernel headers; at
most, you need to say headers from a kernel later than blah).
Ben> The point here is to make packages start moving to Build-Dep'ing on
Ben> kernel-headers-* packages. The question is, how to allow them to do that
Ben> IMO, we can use alternatives. And it should be fairly easy
And hard code paths, unfortunately.
Ben> CFLAGS += -I/usr/src/kernel-headers-2.2/include
Ben> And not have to worry about all the revisions, or detecting anything
How do I build two packages that have different kernel header
Ben> Xu, can this alternative system be added to the kernel-headers package
Ben> scripts? Does anyone see a problem with this solution (that isn't
Ben> already a problem with the current usage of kernel headers in libc6-dev
Ben> that is)? Anyone got a solution for the -preX case, which would probably
Ben> make this method rock solid?
Yes, I do. I think a less complex solution, that does not
necesitate people installing debian kernel headers packages if
they already have their own sources, or to have to build the package
Try this: suggest the kernel-headers package, and set
CFLAGS += -I$(KSRC)/include
and instruct people to set the KSRC variable as needed.
a) I do not want to hardcode /usr/src
b) I do not want to hard code official debian header packages
c) I do want to be able to build modules that require different
kernel headers on the same box (I have one box where I do all my
d) I do not want the kludge that is implied in the update
Have a default value for KSRC if you need, and arrange for the
buildd's to create the /default-ksrc/../kernel-headers-X.X.
Q: What do you call 15 blondes in a circle? A: A dope ring. Q: Why
do blondes put their hair in ponytails? A: To cover up the valve
Manoj Srivastava <email@example.com> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C