>>"Sam" == Sam Hartman <[EMAIL PROTECTED]> writes:
Manoj> We already have a process for packages that actually do
Manoj> need kernel headers, and are thus dependent on particular
Manoj> kernel versions.
Sam> We do? please explain what it is.
Manoj> We call these packages kernel modules; and we have a
Manoj> process by which you inform make where the relevant kernel
Manoj> headers are to be found. make-kpkg automates that somewhat
Manoj> (and make-kpkg can be used for packages that are not
Manoj> kernel-modules, you know).
Sam> How do I use make-kpkg to build modules with a kernel headers
Sam> package?
As you can see above, I never said kernel headers *package*. I
reiterate, we have a process for modules that need kernel-headers,
and that is provided by a process similar to the one employed by
kernel-package (using kernel sources). It is trivial to create a
script that will work with kernel-headers as well.
kernel-package was designed to work with kernels and kernel
modules, and for these one generally needed to configure the kernel
locally (most modules have to be turned on during configuration).
I am not saying we do not need to facilitate third party
software that requires kernel headers to build. I am coming out in
strong objection to the symlink shennanigans we have gotten away from
in the past, for precisely the reasons we got away from them in the
first place.
For a developer packaging a package, it is a trivial effort to
allow for a location to be provided either on the command line, or a
envritonment variable, (perhaps looking at a few ``standard''
locations first. We can even have the config process ask the
developer, as vmware does when compiling its modules.
manoj
--
It's a good thing we don't get all the government we pay for.
Manoj Srivastava <[EMAIL PROTECTED]> <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
