Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
X-Authentication-Warning: hp2.xraylith.wisc.edu: khan owned process doing -bs
Date: Mon, 28 Feb 2000 18:54:51 -0600 (CST)
From: Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>
To: Cygwin Developers List <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: FS layout issues for v1.1 (eg., /bin and /usr/bin)
Message-ID: <Pine.HPP.3.96.1000228182811.25928A-100000@hp2.xraylith.wisc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I had recently asked Chris if he would support the idea of making /bin
and /usr/bin point to the same directory (the `how' comes later), and
he'd asked me bring this out here for a wider discussion. I'm going
to expand the discussion a bit to also talk about where the system
includes and libraries go.

I'm going to leave releases b20.1 and earlier out of the discussion since 
the layout is a confusing mess.

In Cygwin v1.0, Cygwin finally moved into a reasonable layout with (IMO)
two exceptions:
  
1 it used an "interesting" layout where the binaries go to /bin and
  other things go into /usr. In GNU package terminology, it's equiv
  to specifying ``--prefix=/usr --exec-prefix=/''.

  I'd like to see /bin and /usr/bin "point" to the same place in the
  filesystem for the next net release.

2 The system includes are still buried in /usr/<PLATFORM>/include and
  system libraries in /usr/<PLATFORM>/lib, where PLATFORM is something
  like i686-pc-cygwin, i686-cygwin, etc.

  I'd like to see system includes and libraries go in /usr/include and
  /usr/lib respectively, *and* /usr/lib and /lib point to the same place
  in the filesystem. 

One consequence of (1) is that you have to be extra careful in building
and installing packages (real problem IMO), and the other is that we
lose symmetry (I like symmetry). Historically, Unix systems have always 
had a /bin and /usr/bin, and the reason had mostly to do with expensive 
disks, diskless or semi-diskless workstations and other things not really
relevant today. Having /bin is important since that's the only thing we 
can depend on (#!/bin/sh); at the same time, we want symmetry, and would 
like /usr/bin as well. On systems such as Cygwin, there is no reason to 
maintain both separately, and these should simply point to the same place.

The question is -- how do we make /bin and /usr/bin the same?

a. Symlinks: cygcheck could check and report this if the user somehow
   deletes it.
b. Cygwin mount table: It's like a loopback mount used by quite a few
   systems, and even on windows by UWIN:

  $ mount |grep LOFS
  /usr/bin on /bin type LOFS (ic,text,grpid,suid,rw)
  /usr/lib on /lib type LOFS (ic,text,grpid,suid,rw)
  /usr/etc on /etc type LOFS (ic,text,grpid,suid,rw)
  /usr/dev on /dev type LOFS (ic,text,grpid,suid,rw)

The consequence of (2) is more subtle, and, IMO more serious -- it creates 
a dependency on the platform name used by the maintainers, and maintaining 
consistency is easier said than done. We've already gone through 3 -- 
i586-cygwin32, i686-cygwin and now i686-pc-cygwin -- and all of these 
impose a dependency that can be avoided.

We can fix (2) by simply changing the way the Cygwin/winsup installation
works and installing things to /usr/include and /usr/lib (and make /lib
point /usr/lib for the same reasons I'd like to /bin point to /usr/bin).

There are a few side-effects of moving the includes from "target" include
directory /usr/include, but it only has to do with how gcc orders the
include path. I believe I can address those issues if we indeed have any.

Regards,
Mumit