Mail Archives: cygwin/1999/06/21/17:40:45
Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Date: Mon, 21 Jun 1999 16:47:47 -0400
From: Phil Edwards <pedwards AT jaj DOT com>
> In recent threads almost everybody seems to enthusiastically
> agree that the directory cygwin-b20/H-i[3456]86-cygwin32 is in
> analogy with /usr under Unix and that linking or mounting it
> accordingly will enhance the Unix look & feel. This was slightly
> surprising to me because I have from the start had a link /usr ->
> /cygwin-b20.
It isn't to "enhance" the Unix look and feel. It's to get the
whole damn thing working like other Unixes in the first place. :-)
Part of the issue is that (for the compiler and libraries at least)
there is still this subsconscious "everything is in /usr/local and
the stuff in /usr are native tools" tendency. It makes for real
headaches under Linux (where the native tools ARE the GNU tools),
Try to tell this to Rich Pieri. I tried to argue merely that there
are some EXCEPTIONS to the GNU directory scheme under Linux, and I got
the "you don't know what you're talking about" treatment.
My opinion is that /usr/local in general IS useful both for Linux and
for Cygwin. The distinction is not one of native vs. GNU tools as you
point out, but one of distribution vs. local additions. So the Cygwin
full.exe should unpack to (an equivalent of) /usr, while packages from
the Franken acrhive unpack correctly to /usr/local. If a locally
installed package "shadows" a distributed one that's OK too.
The exceptions are programs and files which are part of the system and
cannot be "shadowed", i.e. /bin, /sbin, /etc, /lib, /dev.
--
Ian Zimmerman
Lightbinders, Inc.
2325 3rd Street #324
San Francisco, California 94107
U.S.A.
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -