Re: Bug#43928: libc and kernel source policy
Hi, Paul == Paul Wade [EMAIL PROTECTED] writes: Paul Recently I built the latest X for slink and did so by installing Paul kernel-headers (2.2.12) and the legacy symlinks for Paul /usr/include/(asm,linux). Seems X needed some constants for support of Paul newer hardware. First: you are now one amongst a handful of people who have compiled their won X system. People who can do that know how to get newer kernel header files, as they need them, and you are talking here about the very tail end of the bell curve. Paul Do we assume that people only compile things on unstable Paul systems? No. But you are asking for headers that are not provided on Debian's stable system -- if you are looking for support for hardware or software not shipped with slink, you may reasonably expect to have to upgrade to unstable for native support; or else hack, like you did. Paul If policy can't cover the variety of situations properly, it Paul should be weakened to at least allow easier solutions. Nothing covers all situations completely. You want policy to now cater to people building arcane software (yes, building X is still arcane) with support for newer devices not released when stable was released, and yet not wanting to upgrade to unstable? I am afraid I do not find that reasonable. Paul I acknowledge that my systems are no longer stable if we use a strict Paul definition of the term. BINGO!! Paul However, I do believe that we are trying to deliver something Paul different from a Gateway PC preloaded with W98, Office, IE, and Paul a few games. We are also not trying to create a policy that pleases everyone all the time. Paul Does adhering to a policy diminish the usefulness of the Paul system? This should always be seriously considered. It was. We were really concerned about the instability you introduced and dismissed so cavalierly, knowing that the handful of people who really needed newer kernel headers, and knew enough of the dangers introduced by a mismatched libc, would also know enough to handle the situation. I contend that anyone who does not know their way around creating a simple symlink should be thanking the Debian policy. manoj -- If your life was a horse, you'd have to shoot it. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Bug#43928: libc and kernel source policy
Hi, Paul == Paul Wade [EMAIL PROTECTED] writes: Paul Maybe the role of policy is primarily oriented towards Paul delivering a stable base system and maybe that doesn't apply Paul any more when you start modifying things and building things on Paul your own. Your machine, your rules. Policy only applies to developers *uploading* a package into the distribution. Sysadmins are perfectly able to do whatever they wish on theor own machines, as long as they take responsibility. manoj -- As flies to wanton boys are we to the gods; they kill us for their sport. Shakespeare, King Lear Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Bug#43928: libc and kernel source policy
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/
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:[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]
Re: Bug#43928: libc and kernel source policy
On Wed, Oct 27, 1999 at 11:10:33AM -0400, [EMAIL PROTECTED] wrote: Does adhering to a policy diminish the usefulness of the system? This should always be seriously considered. Not when policy is aiding in stability. Ben
Bug#43928: libc and kernel source policy
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.
I wish to change Debian policy regarding libc and the kernel sources.
The document /usr/share/doc/libc6/FAQ.Debian.gz states:
Occasionally, changes in the kernel headers cause problems with the
compilation of libc and of programs that use libc. To ensure that users
are not affected by these problems, we configure libc to use the headers
from a kernel that is known to work with libc and the programs that
depend on stable kernel headers.
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).
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
Kernel-headers packages might be unnecessary, given your argument.
Kernel-source, though: what planet are you on?
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)?
Again, let's hear what the libc guys have to say before being too
radical.
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).
Not necessarily.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#43928: libc and kernel source policy
On Tue, Oct 26, 1999 at 12:45:20PM +0100, Julian Gilbey wrote:
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.
I wish to change Debian policy regarding libc and the kernel sources.
The document /usr/share/doc/libc6/FAQ.Debian.gz states:
Occasionally, changes in the kernel headers cause problems with the
compilation of libc and of programs that use libc. To ensure that users
are not affected by these problems, we configure libc to use the headers
from a kernel that is known to work with libc and the programs that
depend on stable kernel headers.
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).
Given that they don't change much, what is the argument against having
static ones installed with libc-dev? Your argument tends to assert that there
is actually nothing wrong with this policy. Personally, I would hope that
it always stays this way. For the non-i386 archs, it makes for much less
bug reports, and more stable/consistent builds.
Perhaps the real argument should be, to have something that allows the
users to specify their own headers without libc-dev overwriting them.
Ben
Bug#43928: libc and kernel source policy
On Tue Oct 26, 1999 at 10:21:21AM -0400, Ben Collins wrote: Perhaps the real argument should be, to have something that allows the users to specify their own headers without libc-dev overwriting them. That was indeed the problem that caused my concern. When I am hacking on the kernel and/or working with development kernels, it is very inconveinient to have one's kernel headers removed fro /usr/include -Erik -- Erik B. Andersen Web:http://www.xmission.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons--
Bug#43928: libc and kernel source policy
On Tue, Oct 26, 1999 at 09:40:57AM -0600, Erik Andersen wrote: On Tue Oct 26, 1999 at 10:21:21AM -0400, Ben Collins wrote: Perhaps the real argument should be, to have something that allows the users to specify their own headers without libc-dev overwriting them. That was indeed the problem that caused my concern. When I am hacking on the kernel and/or working with development kernels, it is very inconveinient to have one's kernel headers removed fro /usr/include Then could you note that by retitling the bug report, and making it priority wishlist? Ben
Bug#43928: libc and kernel source policy
On Tue, Oct 26, 1999 at 10:21:21AM -0400, Ben Collins wrote: is actually nothing wrong with this policy. Personally, I would hope that it always stays this way. Ditto. For the non-i386 archs, it makes for much less bug reports, and more stable/consistent builds. FWIW, stability and consistency are the primary reasons I started the current convention a few years ago and those reasons are still valid today. Perhaps the real argument should be, to have something that allows the users to specify their own headers without libc-dev overwriting them. There is -- it's called gcc -I. David -- David Engel [EMAIL PROTECTED]
