Re: Bug#43928: libc and kernel source policy
Recently I built the latest X for slink and did so by installing
kernel-headers (2.2.12) and the "legacy" symlinks for
/usr/include/(asm,linux). Seems X needed some constants for support of
newer hardware. I could have installed kernel-source and I could have even
changed the X source default include path. I don't think that policy
provided any ideal solution.
I notice that pci.h has grown from 37k to 48k since slink was released.
Soon we will have to deal with frequent updates for USB and infrared
hardware as well.
Do we assume that people only compile things on unstable systems? I don't
object to the fact that manual tweaking is needed to build certain
packages. I do wonder if policy is correct in areas such as this. If
policy can't cover the variety of situations properly, it should be
weakened to at least allow easier solutions.
I acknowledge that my systems are no longer "stable" if we use a strict
definition of the term. However, I do believe that we are trying to
deliver something different from a Gateway PC preloaded with W98, Office,
IE, and a few games.
Does adhering to a policy diminish the usefulness of the system? This
should always be seriously considered.
+----------------------------------------------------------------------+
+ Paul Wade Greenbush Technologies Corporation +
+ mailto:paulwade@greenbush.com http://www.greenbush.com/ +
+----------------------------------------------------------------------+
On Tue, 26 Oct 1999, Joel Klecker wrote:
> Date: Tue, 26 Oct 1999 22:54:17 -0700
> From: Joel Klecker <jk@espy.org>
> To: 43928@bugs.debian.org
> Cc: debian-glibc@lists.debian.org
> Subject: Bug#43928: libc and kernel source policy
> Resent-Date: Wed, 27 Oct 1999 06:03:01 GMT
> Resent-From: Joel Klecker <jk@espy.org>
> Resent-To: debian-bugs-dist@lists.debian.org
> Resent-cc: Debian Policy List <debian-policy@lists.debian.org>
>
> >This should certainly be discussed with the libc maintainers before
> >making such a proposal. I am sure that they did not take the decision
> >lightly.
>
> <<
> The kernel headers don't change much these days on stable releases, yet
> the Debian libc packages continue to carry with them full sets of kernel
> headers (whatever somebody has _manually_ copied into place as
> /usr/include/{linux,asm,scsi,etc} on the system building glibc).
> >>
>
> That's false, the headers are copied from
> $(LINUX_SOURCE)/include/{asm,linux}, which is never /usr/include.
>
> <<
> Why in the heck do we have kernel-headers packages in Debian? Why
> do we have kernel-source packages? It seems to me that if building
> libc _requires_ a particular set of kernel include files (which I
> consider to be dubious) why not have glibc _depend_ on a particular
> kernel-headers-xxx package? Why not have kernel headers provide
> /usr/include/{linux,asm,scsi,etc} (or at least put in symlinks
> for them pointing to /usr/src/kernel-headers-xxx)?
> >>
>
> At this moment, kernel-headers packages exist for probably just
> building glibc, having a fixed place for the headers makes it
> possible for glibc to be autobuilt or at least makes it easier for
> the person building it.
>
> We already did the libc6-dev depends on kernel-headers-x.x.x method,
> there were countless bugs filed against libc6-dev by idiots who
> didn't understand why when they upgraded their kernel that libc6-dev
> still wanted "old" kernel headers. Finally the kernel-package and
> glibc maintainers got fed up and just copied the headers directly
> into libc6-dev.
>
> <<
> That would be a great service to kernel hackers, libc hackers, and
> mirror maintainers (since libc would no longer have to carry around
> the extra baggage of kernel headers).
> >>
>
> kernel hackers do not need /usr/include/{asm,linux} to point to their
> current kernel source. They do not work in userspace.
>
> libc hackers don't need that either, since they have --with-headers.
>
> Incidentally, I don't think policy has any business telling me what
> goes in /usr/include (besides not to put non-headers there by
> reference of the FHS).
> --
> Joel Klecker (aka Espy) Debian GNU/Linux Developer
> <URL:mailto:jk@espy.org> <URL:mailto:espy@debian.org>
> <URL:http://web.espy.org/> <URL:http://www.debian.org/>
>
>
> --
> To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: