X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=2.1 required=5.0 	tests=AWL,BAYES_00,J_CHICKENPOX_33,J_CHICKENPOX_43,RCVD_IN_JMF_BL
X-Spam-Check-By: sourceware.org
Message-ID: <4AB1BF25.5030405@shaddybaddah.name>
Date: Thu, 17 Sep 2009 14:46:29 +1000
From: Shaddy Baddah <helium AT shaddybaddah DOT name>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: goldstar? Re: cygdrive prefix
References: <ee47a1dc39b42cb6fdd0c2dff9ff3053 AT mail DOT smartmobili DOT com> 	 <h8r26b$peb$1 AT ger DOT gmane DOT org> 	 <182640b4a6730dafadd266e0cfc9d9bf AT mail DOT smartmobili DOT com> 	 <h8ripc$itl$1 AT ger DOT gmane DOT org> 	 <416096c60909161406tbfd73ey7a5b9510e7f97762 AT mail DOT gmail DOT com> 	 <4AB1924F DOT 80005 AT shaddybaddah DOT name> 	 <20090917014400 DOT GB25602 AT ednor DOT casa DOT cgf DOT cx> <f60fe000909161906paf3ea99s407552cd8105bc4d AT mail DOT gmail DOT com>
In-Reply-To: <f60fe000909161906paf3ea99s407552cd8105bc4d@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Hi,

Before I start, I want to admit that I think I may have
misinterpreted Andy Koppe's email. I now see that Andy may have been
defending *not* demarcating the rest of the windows world with a
/cygdrive prefix by just having all c:/ subpaths accessabile directly
from the / prefix. That's not my style, but its an OK choice to have.

In my defence, when people advocate (or appear to advocate as in this
case) having a c:/bin,c:/lib,etc., I get the impression that they want
to unify the installation of all non-OS packages into the one
location. In which case I would still stand by my argument. If this is
not what you were advocating, I am sorry that I have misinterpreted
your post Andy (you can take my star away now, I wont mind :-) ).

Which leads me to this:

Mark J. Reed wrote:
<snip>
 > Really, the two modes of operation don't talk to each other much. They
 > just share a filesystem.  It works because they mostly leave each
 > other alone.  There's no tradition in Mac land of creating a top-level
 > "bin" folder and putting things in there, because there was no command
 > line at all on the traditional Mac OS, so there was no point.  Which
 > means the sort of conflicts mentioned by Shaddy rarely arise.

I'm a little confused? Wasn't I, by initial interpretation of Andy
Koppe's response, saying that having a /bin on Mac OS was ok because
it avoided the conflicts by being administered by MacPorts (that's the
correct name, thanks). In the same way most Linux distros do that with
dpkg,rpm,or other. Sure it could be administered by Fink or some other
package management system, but the point still stands, I wasn't saying
that there were conflicts on Mac OS at all.

Shaddy Baddah wrote:
 > I don't run an Apple computer OS, but my observation is that they are
 > based around a packaging system called 'port'? If true, that
 > undermines your argument somewhat. Because then you are even with
 > Linux/most unices, which of course carefully drop all exes into bin,
 > libraries into lib, etc. In this case there is nothing wrong dropping
 > everything into a single bin,lib,.. dir as you say, because there is a
 > package management system there to hold manifests, handle collisions,
 > allow uninstalls etc. etc. But without a package management system,
 > you are asking for trouble.

Anyway, I think I'll stop commenting on Mac OS now because truth be
told, I've had little experience with it.

Regards,
Shaddy


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple