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

Re: PW#5-16: Use of /usr/src

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


 When bad men combine, the good must associate; else they will fall
 one by one, an unpitied sacrifice in a contemptible struggle. Edmund
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: