directory structure

[itz@lbin.com]

   Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
   Precedence: bulk
   Sender: cygwin-owner@sourceware.cygnus.com
   Delivered-To: mailing list cygwin@sourceware.cygnus.com
   Date: Mon, 21 Jun 1999 16:47:47 -0400
   From: Phil Edwards <pedwards@jaj.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@sourceware.cygnus.com