On Sat, May 18, 2002 at 01:25:12PM -0500, Steve Langasek wrote: > On Sun, May 19, 2002 at 12:09:05AM +1000, Glenn McGrath wrote: > > On Sat, 18 May 2002 10:07:41 -0300 > > "Henrique de Moraes Holschuh" <hmh@debian.org> wrote: > > > > On Sat, 18 May 2002, Glenn McGrath wrote: > > > > Maybe small parts of the FHS cause trouble for the Hurd; these could be > > > changed for Debian. HOWEVER, Debian GNU/Hurd is *not* to be GNU/Hurd > > > with Debian packages. It is to be a _Debian_ system with the Hurd > > > kernel. So, whatever isn't kernel-specific IS supposed to be the same. > > > If being"Hurdish" is more important to you than being "Debianish", then > > > as far as*I* am concerned, you are welcome to fork the project, and go > > > away. > > > You would have to drag me kicking and screaming. > > > > If you cannot agree to that, and do notice I never said we shouldn't > > > change a few things on the way the filesystem is currently laid out in > > > the Debian GNU/Linux side of things (FHS or no FHS), then you will be in > > > for a very rough ride. > > > And if Debian is commited to the LINUX Standards Base, do you expect > > Debian GNU/hurd and Debian *bsd(s) to also comply to the LINUX Standards > > Base ? > > I assume that you're suggesting here that standardizing on the LSB would > be a logical next step for Linux supporters to take after the FHS. > That's not the case. The FHS is useful to Debian because having *some* > standard describing the system layout is necessary to ensure that we > produce an internally-consistent system that's easy for both users and > other developers to work with; and all other things being equal, using > a common standard is better than developing our own because it lets us > leverage greater mindshare. In stark contrast, the LSB is a standard > that only benefits /vendors/ directly; indeed, by requiring conformance > with a frozen ABI, the LSB makes /more/ work for developers. If the LSB > is supported at all, it will be through the efforts of a small group of > concerned developers to bring this about in a policy-conformant way -- > *not* through the use of policy as a club. It's useful to have such a standard, that's why it's specified in the GNU Coding Standard. I don't think the FHS is a good standard however. 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. > That being the case, I can't imagine that anyone's going to expect the > Debian Hurd port to be ABI-compatible with a vendor specification > written for a different kernel that's external to Debian itself. I can image, because it's not that difficult to do and you get a lot from it. The only problem is that we also get some things we don't want: non-free (binary-only) software for GNU/Linux would also run on GNU/Hurd. And that's why we aren't going to do any Linux emulation and aren't going to be LSB-compliant. Jeroen Dekkers -- Jabber ID: jdekkers@jabber.org IRC ID: jeroen@openprojects GNU supporter - http://www.gnu.org
Attachment:
pgpEs2BkJWeXq.pgp
Description: PGP signature