On Sun, May 19, 2002 at 12:36:35AM +0200, Wouter Verhelst wrote:
> On Sat, 18 May 2002, Jeroen Dekkers wrote:
> > It's useful to have such a standard, that's why it's specified in the
> > GNU Coding Standard.
>
> Well, but GNU != Debian. Debian follows Debian Policy, not the GNU Coding
> Standard. If you want Debian to follow the GNU Coding Standard, go to
> debian-vote and issue an amendment to throw away Debian Policy (or any
> part thereof) and replace it with the GNU Coding Standard. If you get the
> majority of Debian's developers to agree, then we'll follow the GNU Coding
> Standard; until that time, Hurd developers need to follow Debian Policy
> wherever possible, even if it's braindead (which I don't think it is, but
> just in case).
Debian GNU/Hurd are 2 things. One is Debian. The other is GNU/Hurd
and the Hurd is GNU too, so it's actually just GNU. Is it so
difficult to see that? A lot of packages in Debian follow the GNU
Coding Standards because a lot of them come from GNU. And upstream
Hurd developers are following the GNU Coding Standards, because the
Hurd is GNU software. Is Debian willing to maintain all the patches
for that software so it's compatible with the FHS instead of the GCS?
> > I don't think the FHS is a good standard
> > however.
>
> That's your good right. Still, Debian uses FHS, so Debian GNU/Hurd will
> also be FHS-compliant. Else it won't be Debian GNU/Hurd. What's so hard
> about that?
IMHO it won't be GNU/Hurd without being compliant with the GNU Coding
Standards. And are you also asking the Debian *BSD people to change
their ABI because of the FHS? I asked them what they thought about
libexec and the FHS etc. and they said to me that they won't give up
ABI compatibility for the FHS. So what do you think, should we get rid
of both the Hurd and BSD ports or change Debian policy?
> I can understand that certain packages, like inet-utils for example,
> cannot be ported to Debian GNU/Hurd and thus need to be packaged
> separately. But that does not go for the filesystem. Debian GNU/Hurd
> will still be Debian; If GNU doesn't like that, then GNU must make
> it's own Hurd-distribution, and not try to change Debian.
Do you mean the Linux netkit instead of inet-utils? Inetutils is GNU
software and works fine GNU/Hurd, *BSD and GNU/Linux (minus bugs). So
it is possible to have a coherent system. Is Debian GNU/Linux going to
make GNU inetutils and abandon the netkit package? If not, why should
we make the FHS the default on GNU/Hurd then?
> > The fact is that the loader in *BSD is in libexec and that's
> > part of the ABI. It isn't in GNU/Hurd, I don't know why, maybe to be
> > compatible with GNU/Linux or for some other reason.
>
> Simply because libexec isn't FHS-compliant. You knew that already.
GNU doesn't care about what some GNU-bashing hobbyists who wrote a
kernel and some other software which is most of the time incompatible
with GNU itself. So I really wonder why it isn't in libexec, because
it should be there.
Before I get 25 "fan mails" that I say "hobbyists" I already back it
up:
"I'm doing a (free) operating system (just a hobby, won't be
big and professional like gnu)."
-- Linus Torvalds, 25 Aug 1991
IMHO the same goes for the FHS.
But everything available from GNU was used for 'his operating', we
have now the GNU OS with the kernel Linux and some other things not
available from GNU at that time and we call that GNU/Linux. And that's
exactly why it should be called like that. Linus' initial goal isn't
irrelevant to that. But telling this is useless anyhow as a lot of
people don't want to see it. It's just that it only takes a minute.
This is also a reason why I don't want to be in Debian. Most of the
time the system is just called "Linux" by people who already know that
it should actually be "GNU/Linux". I can't work with people who say
wrong things when they are told it's wrong and the project already
decided to say the right thing.
Sometimes the truth isn't the same as what you want to see.
Jeroen Dekkers
--
Jabber ID: jdekkers@jabber.org IRC ID: jeroen@openprojects
GNU supporter - http://www.gnu.org
Attachment:
pgpZGUpXzLLWh.pgp
Description: PGP signature