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:[EMAIL PROTECTED] http://www.greenbush.com/ + +----------------------------------------------------------------------+ On Tue, 26 Oct 1999, Joel Klecker wrote: > Date: Tue, 26 Oct 1999 22:54:17 -0700 > From: Joel Klecker <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > 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:[EMAIL PROTECTED]> <URL:mailto:[EMAIL PROTECTED]> > <URL:http://web.espy.org/> <URL:http://www.debian.org/> > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
