Re: PW#5-16: Use of /usr/src
Hi,
>>"Ian" == Ian Jackson <ian@chiark.greenend.org.uk> writes:
Ian> Manoj (SuperCite undone): [ Ian: ]
>> > The package that the libc depends on (libc-kernelheaders perhaps)
>> should be a plain .deb file which installs in
>> /usr/include/{asm,...}. The libc should specify the version number
>> via a dependency, rather than by changing the package name, because
>> there is no need or desire to have several sets of kernel headers
>> all available in /usr/include.
>>
>> There has been a long discussion on this topic. I fail to see the
>> advantage of creating a special purpose package just for libc
>> purposes.
Ian> Err, but you are also advocating creating or maintaining a
Ian> special purpose package just for libc purposes. Your statement
Ian> is as much of an attack on the status quo as on my proposal.
Umm, no. The kernel-* package maintainers use kernel-package,
which produces (and has produced, in the past) the packages
kernel-{headers,source,doc,image}-<version>. There is no interaction
required between the two sets of maintainers (libc-dev and kernel-*)
>> I have been informed there is sufficinet interest in a
>> kernel-headers package by people tinkering with modules to warrant
>> its inclusion in the distribution.
Ian> I wasn't suggesting abolishing the package which these people
Ian> use. I was suggesting changing its internal structure and its
Ian> name.
But that is duplication of a package; it shall exists as
kernel-headers-<version> and libc-kernel-headers, the former since it
is automatically produced for all kernel-* packages (offcial or
unofficial packages); it is produced since people still use it.
Since kernel-headers-<version> shall always exist; it seems
ill advised to create an almost identical package, moreever, since
the process requires additional synchrojnization between the kernel-*
packages maintainer and the libc maintainer, for, pardon me, very
little gain.
>> If kernel headers are to be included anyway (and there are really a
>> large number of people who have informed me that they use the
>> packages), then it reduces the bureaucratic interaction between the
>> libc maintainers and the kernel package maintainers.
>>
>> For example, when the kernel-* package maintainers release 2.0.34,
>> the libc6 maintainer can just upgrade libc6-dev, and point to the
>> kernel-headers-2.0.34. No special packages, no prior communication
>> between maintainer, no extra synchronization between kernel-*
>> maintainers and libc6-dev maintainers on every supported
>> architecture required.
Ian> This is still true if instead of kernel-headers-2.0.34 (2.0.34-1)
Ian> installing in /usr/src we have kernel-headers (2.0.34-1)
Ian> installing in /usr/include.
I have, at the moment, 2 different kernel-header packages from
two different kernel versions. I use them for experimental modules
that I build. That is reason enough for kernel-headers-2.0.34.
Additionally, since we do need kernl-image-<version> etc anyway,
acceding to this preserves the consistency in the packages produced
(namely kernel-{headers,source,doc,image}-<version>).
I still think that this is a working solution, and, in my eyes
at least, an aesthetically pleasing one as well. I think I would
require stronger technical arguments to make me change my mind.
manoj
--
When bad men combine, the good must associate; else they will fall
one by one, an unpitied sacrifice in a contemptible struggle. Edmund
Burke
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
E-mail the word "unsubscribe" to debian-policy-request@lists.debian.org
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to listmaster@lists.debian.org
Reply to: