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

Re: Problem with dpkg-source

I know, I know, don't attack me so fast.  All i was trying to do was 
figure out a way so that dpkg-source doesn't scream.  I know we can get 
some bad header files in there.  Well I don't know what I was originally 
thinking now, damn cold, but I know it was not meant to say put in any 
header files.


On 19 Feb 1997, Manoj Srivastava wrote:

> Hi,
> >>"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.
> 		manoj
> -----------------------------------------------------------------
>         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
>  good.
> 	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
>  gracefully.
> 	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
>  dependencies.
>         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/>

This message was delayed because the list mail delivery agent was down.

Reply to: