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

Re: build depends on kernel-headers



>>"Ben" == Ben Collins <bcollins@debian.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
 structures. 

 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> easily.

 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
 Ben> special.

	How do I build two packages that have different kernel header
 requirements? 

 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
 as root

	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
    kernel builds)
 d) I do not want the kludge that is implied in the update
    alternatives. 

	Have a default value for KSRC if you need, and arrange for the
 buildd's to create the /default-ksrc/../kernel-headers-X.X.


	manoj
-- 
 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
 stem.
Manoj Srivastava   <srivasta@debian.org>  <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



Reply to: