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:
pgpTvdSRaGjK2.pgp
Description: PGP signature