From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32113 invoked by alias); 3 Apr 2008 23:06:56 -0000 Received: (qmail 32081 invoked by uid 22791); 3 Apr 2008 23:06:53 -0000 X-Spam-Check-By: sourceware.org Received: from out4.smtp.messagingengine.com (HELO out4.smtp.messagingengine.com) (66.111.4.28) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Apr 2008 23:06:34 +0000 Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 43A30E4333; Thu, 3 Apr 2008 19:06:32 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 03 Apr 2008 19:06:32 -0400 Received: from [192.168.1.2] (user-0c6suln.cable.mindspring.com [24.110.122.183]) by mail.messagingengine.com (Postfix) with ESMTPSA id AEB00B6C2; Thu, 3 Apr 2008 19:06:31 -0400 (EDT) Message-ID: <47F561D1.60706@cwilson.fastmail.fm> Date: Thu, 03 Apr 2008 23:06:00 -0000 From: Charles Wilson User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Mailing List: CygWin-Apps , cygwin-developers@cygwin.com Subject: Re: [HEADSUP] Let's start a Cygwin 1.7 release area References: <20080402123551.GB4468@calimero.vinschen.de> <20080402174556.GI4468@calimero.vinschen.de> <47F40F16.8080303@cwilson.fastmail.fm> <20080403094220.GA21673@calimero.vinschen.de> <20080403135620.GA9219@ednor.casa.cgf.cx> <20080403141958.GM4468@calimero.vinschen.de> In-Reply-To: <20080403141958.GM4468@calimero.vinschen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com X-SW-Source: 2008-04/txt/msg00052.txt.bz2 Corinna Vinschen wrote: > On Apr 3 09:56, Christopher Faylor wrote: >> For 1.7, I think we ought to decouple /bin <> /usr/bin and /lib <> >> /usr/lib. The rationale for keeping those linked no longer applies in >> the modern setup.exe world. > > Full ACK! However, this needs a bit of careful revisiting of some of > the packages. For instance, assuming the Cygwin DLL will go to /bin, > cygrunsrv should also reside in /bin when we do this, not in /usr/bin, > obviously. Right now I must admit that I prectically don't care if my > packages install the binaries in /bin or /usr/bin. Yep. A few things off the top of my head: 1) the shells need to install both in /bin and /usr/bin. This is up to the individual maintainers when they build their -1.7 versions, but to take on super-duper important shell: C:\cygwin/bin\bash.exe C:\cygwin/bin\cygwin1.dll C:\cygwin/bin\cygintl-8.dll C:\cygwin/bin\cygiconv-2.dll C:\cygwin/bin\cygreadline6.dll C:\cygwin/bin\cygncurses-8.dll Should /bin/bash be built "statically" (at least with regards libintl/libiconv/libreadline/libncurses)? Should /usr/bin/bash be identical to /bin/bash and also built statically? Or should bash-3.x.y-z.tar.bz2 for cygwin-1.7 have two separate (and different) bash executables in it? What if that tarball (with different /usr/bin/bash and /bin/bash) is unpacked on a system where "legacy" /usr/bin->/bin mounts are present? Or should some "important" set of DLL libraries be installed into both /usr/bin/ and /bin, and then /usr/bin/bash.exe and /bin/bash.exe (and /bin/sh.exe) can all be exactly the same, built using dynamic links, just as /usr/bin/bash.exe is today? Or "tough. you want to run /bin/bash, ensure /usr/bin is in your PATH" 2) build tools (netrel, gbs, cygport) might need a few additions/tweaks to support any of the above. > I don't know. I assume I just took this as it is. I guess the > only reason to create user mounts to begin with was, so that any > non-privileged user can create mount points, too, for a pure > "just me" installation in a restricted environment. > > However, that's not really necessary anymore with /etc/fstab. > So I agree, we can simply get rid of fstab.$SID. No, please don't...I like my /desktop mount... -- Chuck