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

Re: Problem with dpkg-source

>>"Shaya" == Shaya Potter <spotter@itd.nrl.navy.mil> writes:

Shaya> David, I was thinking, isn't it a bad idea to have those
Shaya> headers in the package, b/c lets say someone downloads the
Shaya> source pacakge and rebuilds it to a different kernel version.
Shaya> He'll have your source files, wouldn't it be better to have a
Shaya> variable that can be set to wherever a persons kernel source
Shaya> is, and copy the headers from there during a build.

	*sigh*. This is just a variation of the FAQ "Should I have
 symlinks to the kernel headers in /usr/include?", and the answer is
 again, no, we don't want the new kernel includes. Also, When I
 download the sources, I should get the same binary that david
 produces, every person compiling libc should not come up with
 different, incompatible libraries.

	We need to protect the naive from the hooror of bleeding edge
 kernel headers.  If you reely need them you could delete the
 defaults, and substituit your own, but *no way* should that be the
 default action.

	The reasons for all this are in the canned response below.



        The headers were included in libc5-dev after a rash of very
 buggy alpha kernel releases (1.3.7* or something like that) that
 proceeded to break compilations, etc.  Kernel versions are changed
 far more rapidly than libc is, and there are higer chances that
 people install a custom kernel than they install custom libc.

	The kernel headers used to make sense exporting to user space,
 but the user space thing has grown so much that it's really not
 practical any more. And technically, the symlinks really aren't very

	As of glibc, the kernel headers will really be _kernel_
 headers, and user level includes are user level includes, because it
 is no longer possible to try to synchronize the libc and the kernel
 the way it used to be. The symlinks have been a bad idea for at least
 a year now, and the problem is just how to get rid of them

	The _only_ reason for the symlinks is to immediately give
 access to new features in the kernel when those happen. New ioctl
 numbers etc etc. That was an overriding concern early on: the kernel
 interfaces expanded so rapidly even in "normal" areas that having the
 synchronization that symlinks offered was a good thing.

	However, the kernel interfaces aren't really supposed to
 change all that quickly any more, and more importantly: the technical
 users know how to fix things any way they want, so if they want a new
 ioctl number to show up they can actually edit the header files
 themselves, for example. But having separation is good for the
 non-technical user, because there are less surprises and package

        Add to that the fact that few programs really need the more
 volatile elements of the header files (that is, things that really
 change from kernel version to kernel version), [before you reject
 this, consider: programs compiled on one kernel version usually work
 on other kernels].

        So, it makes sense that a set of headers be provided from a
 known good kernel version, and that is sufficient for compiling most
 programs, (it also makes the compile time environments for programs
 on debian machines a well known one, easing the process of dealing
 with problem reports), the few programs that really depend on cutting
 edge kernel data structures may just use -I/usr/src/linux/include
 (provided that kernel-headers or kernel-source exists on the system).

        Most programs, even if they include <linux/something.h>, do
 not really depend on the version of the kernel, as long as the kernel
 versions are not too far off, they will work. And the headers
 provided in libc5-dev are just that. 

        libc5-deb is uploaded frequently enough that it never lags too
 far behind the latest released kernel.

        There are two different capabilities which are the issue, and
 the kernel-packages and libc5-dev address different ones:

 a) The kernel packages try tp provide a stable, well behaved kernel
    and modules, and may be upgraded whenever there are significant
    advances in those directions (bug fixes, more/better module
    support, etc).  These, however, may not have include files that
    are non-broken as far as non-kernel programs are concerned, and
    the quality of the development/compilation environment is not the
    kernel packages priority (Also, please note that the kernel
    packages are tied together, so kernel-source, headers, and image
    are produced in sync)

 b) Quality of the development/compilation environment is the priority
    of libc5-dev package, and it tries to ensure that the headers it
    provides would be stable and not break non-kernel programs. This
    assertion may fail for alpha kernels, which may otherwise be
    perfectly stable, hence the need for a different set of known-good
    kernel include files.


 Many alligators will be slain, but the swamp will remain.
Manoj Srivastava               <url:mailto:srivasta@acm.org>
Mobile, Alabama USA            <url:http://www.datasync.com/%7Esrivasta/>

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com

Reply to: