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.
Shaya
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: