Ambrose Li wrote:
On Tue, Jan 27, 2004 at 10:06:46AM -0500, Greg Wooledge wrote:
True -- *but*, it must be pointed out that this is historic!
In a modern GNU/Linux distribution, /usr/include/linux should
*not* be a symlink to anything at all. It should be a plain
directory
Thanos Kyritsis wrote:
On Tuesday 27 January 2004 20:39, Robert S. Dubinski wrote:
The Filesystem Hierarchy Standard document version 2.3 of the Linux
Standard Base project (http://www.linuxbase.org/) lists the
following:
As a matter of fact, there is also this
Actually that info is in the Linux file standard, which has been
available for some years. There are some distributions which don't
follow that, all I can say is there is a standard.
Absolutely. Adhering to the standard should be primary concern, the rest
is secondary.
cdrtools should use
On Wed, Jan 28, 2004 at 02:58:45PM +1300, Volker Kuhlmann wrote:
It may be a little tricky on distributions not coming from a commercial
source, like Debian.
Maybe, but it remains entirely Debian's problem and responsibility to
sort out. It's by no means impossible. In any case, as you say, not
Hi,
It may be a little tricky on distributions not coming from a commercial
source, like Debian.
Maybe, but it remains entirely Debian's problem and responsibility to
sort out. It's by no means impossible. In any case, as you say, not
J?rg's problem.
Sorry, _what_ remains Debian's problem
I have a very high respect for Joerg. But please let me comment
a little on this.
Back in the former times (I started using GNU/Linux back
when the only distros were SLS and Slackware), apps assumed
that the kernel header files are in a linux directory in the
system include path (the
On Tue, Jan 27, 2004 at 09:01:56AM -0500, Ambrose Li wrote:
Back in the former times (I started using GNU/Linux back
when the only distros were SLS and Slackware), apps assumed
that the kernel header files are in a linux directory in the
system include path (the /usr/include/linux symlink,
On Tue, Jan 27, 2004 at 10:06:46AM -0500, Greg Wooledge wrote:
True -- *but*, it must be pointed out that this is historic!
In a modern GNU/Linux distribution, /usr/include/linux should
*not* be a symlink to anything at all. It should be a plain
directory containing the kernel header files
Yes, myself is to blame for not checking the updated FHS. But
why would anyone upgrading from libc5 to libc6 suspect that a
change in the FHS should affect the upgrade (esp. if the libc6
docs do not refer to the FHS)?
So my main complaint will be that I'll need to dig around
per se, in unknown
On Tue 27 January 2004 21:41, Robert S. Dubinski wrote:
On Tue, Jan 27, 2004 at 03:10:42PM -0500, Ambrose Li wrote:
Yes, myself is to blame for not checking the updated FHS. But
why would anyone upgrading from libc5 to libc6 suspect that a
change in the FHS should affect the upgrade (esp.
On Tuesday 27 January 2004 20:39, Robert S. Dubinski wrote:
The Filesystem Hierarchy Standard document version 2.3 of the Linux
Standard Base project (http://www.linuxbase.org/) lists the
following:
As a matter of fact, there is also this document:
Some standard needs to finally direct everyone as to where the running
kernel sources are. There are many applications that need the running
kernel sources and not /usr/include/linux.
Yes, I agree with Jörg on this one. Header files are there for a
reason, and that is for programs which need
Hi,
But how is the vendor supposed to know that GNU libc6 requires the
files to be oriented according to the FHS? That should be in the
glibc docs, period.
Who said glibc requires the files be arranged a certain way according
to FHS? The original statement I responded to a few posts ago
Hi,
On Tue, Jan 27, 2004 at 11:32:37PM +0200, Thanos Kyritsis wrote:
As a matter of fact, there is also this document:
http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html
Now, which one is the right one ??
Well, that one appears to be a compilation from various sources.
Hi,
On Wed, Jan 28, 2004 at 12:41:17PM +1300, Volker Kuhlmann wrote:
Users who need to recompile programs are required to have a minimum of
programming knowledge. If they don't, they ought to be using an out of
the box distro (which will have correct headers in the correct place),
or else
It may be a little tricky on distributions not coming from a commercial
source, like Debian.
Maybe, but it remains entirely Debian's problem and responsibility to
sort out. It's by no means impossible. In any case, as you say, not
Jörg's problem.
Volker
--
Volker Kuhlmann is
I have a very high respect for Joerg. But please let me comment
a little on this.
Back in the former times (I started using GNU/Linux back
when the only distros were SLS and Slackware), apps assumed
that the kernel header files are in a linux directory in the
system include path (the
On Tue, Jan 27, 2004 at 09:01:56AM -0500, Ambrose Li wrote:
Back in the former times (I started using GNU/Linux back
when the only distros were SLS and Slackware), apps assumed
that the kernel header files are in a linux directory in the
system include path (the /usr/include/linux symlink,
On Tuesday 27 January 2004 20:39, Robert S. Dubinski wrote:
The Filesystem Hierarchy Standard document version 2.3 of the Linux
Standard Base project (http://www.linuxbase.org/) lists the
following:
As a matter of fact, there is also this document:
Hi,
But how is the vendor supposed to know that GNU libc6 requires the
files to be oriented according to the FHS? That should be in the
glibc docs, period.
Who said glibc requires the files be arranged a certain way according
to FHS? The original statement I responded to a few posts ago
Hi,
On Tue, Jan 27, 2004 at 11:32:37PM +0200, Thanos Kyritsis wrote:
As a matter of fact, there is also this document:
http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html
Now, which one is the right one ??
Well, that one appears to be a compilation from various sources.
Hi,
On Wed, Jan 28, 2004 at 12:41:17PM +1300, Volker Kuhlmann wrote:
Users who need to recompile programs are required to have a minimum of
programming knowledge. If they don't, they ought to be using an out of
the box distro (which will have correct headers in the correct place),
or else
It may be a little tricky on distributions not coming from a commercial
source, like Debian.
Maybe, but it remains entirely Debian's problem and responsibility to
sort out. It's by no means impossible. In any case, as you say, not
Jörg's problem.
Volker
--
Volker Kuhlmann is
Joerg Schilling wrote:
Please don't comment things you obviously don't really understand.
1) The include files on /usr/src/linux have been absolutely needed for a long
time to be able to compile at all.
2) The include files under /usr/src/linux are definitely more recent
resp.
From: [EMAIL PROTECTED]
On 23. January 2004 at 5:40PM +0100,
Joerg Schilling [EMAIL PROTECTED] wrote:
Please don't comment things you obviously don't really understand.
1) The include files on /usr/src/linux have been absolutely
needed for a long time to be able to compile at all.
I don't
From [EMAIL PROTECTED] Sun Jan 25 14:49:03 2004
Please don't comment things you obviously don't really understand.
1)The include files on /usr/src/linux have been absolutely needed for a long
time to be able to compile at all.
2)The include files under /usr/src/linux are
From: Joerg Schilling [EMAIL PROTECTED]
Subject: [Cdrecord-announces] Re: [Cdrecord-video] Re: [Cdrecord-developers]
Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Date: Sun, 25 Jan 2004 19:40:20 +0100 (CET)
OH, yeah. give me more more more of this !!!
I like this kind
Joerg Schilling wrote:
Please don't comment things you obviously don't really understand.
1) The include files on /usr/src/linux have been absolutely needed for a
long
time to be able to compile at all.
2) The include files under /usr/src/linux are definitely more recent
resp.
From: [EMAIL PROTECTED]
On 23. January 2004 at 5:40PM +0100,
Joerg Schilling [EMAIL PROTECTED] wrote:
Please don't comment things you obviously don't really understand.
1) The include files on /usr/src/linux have been absolutely
needed for a long time to be able to compile at all.
I don't
From [EMAIL PROTECTED] Sun Jan 25 14:49:03 2004
Please don't comment things you obviously don't really understand.
1)The include files on /usr/src/linux have been absolutely needed for a
long
time to be able to compile at all.
2)The include files under /usr/src/linux are
On 23. January 2004 at 5:40PM +0100,
Joerg Schilling [EMAIL PROTECTED] wrote:
Please don't comment things you obviously don't really understand.
1) The include files on /usr/src/linux have been absolutely
needed for a long time to be able to compile at all.
I don't have /usr/src/linux and
On 23. January 2004 at 5:40PM +0100,
Joerg Schilling [EMAIL PROTECTED] wrote:
Please don't comment things you obviously don't really understand.
1) The include files on /usr/src/linux have been absolutely
needed for a long time to be able to compile at all.
I don't have /usr/src/linux and
From [EMAIL PROTECTED] Fri Jan 23 14:07:13 2004
attached there is a patch to make cdrtools 2.01 compatible to Linux
2.6.1.
If the patch is not needed for some distros, which are assembled
somehow, it does not harm anything...
Why should I add a wrong definition that would _break_
From: Meino Christian Cramer [EMAIL PROTECTED]
Hi,
attached there is a patch to make cdrtools 2.01 compatible to Linux
2.6.1.
If the patch is not needed for some distros, which are assembled
somehow, it does not harm anything...
Why should I add a wrong definition that would _break_
From: Joerg Schilling [EMAIL PROTECTED]
Subject: [Cdrecord-announces] Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to
make cdrtools 2.01a25 Linux compatible
Date: Tue, 20 Jan 2004 14:18:41 +0100 (CET)
From: Meino Christian Cramer [EMAIL PROTECTED]
Hi,
attached
From: Meino Christian Cramer [EMAIL PROTECTED]
Why should I add a wrong definition that would _break_ compilation
once the Linux kernel include files are fixed?
If you like to get a fix, go to the Linux Kernel people and request
a fix for their bugs!
Jörg
a) The patch isn't wrong.
It
From: Meino Christian Cramer [EMAIL PROTECTED]
Why should I add a wrong definition that would _break_ compilation
once the Linux kernel include files are fixed?
If you like to get a fix, go to the Linux Kernel people and request
a fix for their bugs!
Jörg
a) The patch isn't wrong.
It
37 matches
Mail list logo
