From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15538 invoked by alias); 3 Apr 2008 15:39:07 -0000 Received: (qmail 15506 invoked by uid 22791); 3 Apr 2008 15:39:06 -0000 X-Spam-Check-By: sourceware.org Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 03 Apr 2008 15:38:48 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id AD8F96D430A; Thu, 3 Apr 2008 17:38:44 +0200 (CEST) Date: Thu, 03 Apr 2008 15:39:00 -0000 From: Corinna Vinschen To: cygwin-apps@cygwin.com, cygwin-developers@cygwin.com Subject: Re: [HEADSUP] Let's start a Cygwin 1.7 release area Message-ID: <20080403153844.GA27344@calimero.vinschen.de> Mail-Followup-To: cygwin-apps@cygwin.com, cygwin-developers@cygwin.com 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) 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/msg00043.txt.bz2 [#$%^! I had a reply-to set in my original reply. I removed it. Please reply to *this* mail. Thanks.] On Apr 3 11:16, Igor Peshansky wrote: > On Thu, 3 Apr 2008, Corinna Vinschen wrote: > > [snip] > > > >>> Get own path ==> C:\\cygwin\\bin\\cygwin1.dll > > > >>> Where's fstab? ==> C:\\cygwin\\etc\\fstab > > > >> > > > >> So, it implicitly computes where / is? > > > > > > > >No, it doesn't. It just snips away the last two path components and > > > >tacks the etc/fstab string on. Plus the .$SID to get the user mounts. > > > > > > > >After the mount points have been read, root can potentially be > > > >somewhere else entirely. > > So would it make sense to put the root mount info in the same directory as > cygwin1.dll? I know it doesn't belong in /bin, but playing with relative > paths is even more error-prone. I don't understand this. As discussed somewhat later, if the root dir follows automatically from where the DLL itself resides. Which, btw., the current code doesn't do right. I called GetModuleFileName(NULL) which returns the path of the current application, not the path of the Cygwin DLL. I'll fix that. > > [snip] > > > 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. > > Umm, i don't see how that follows. cygrunsrv can easily reside in > /usr/bin, as long as (a) /bin is in the PATH when cygrunsrv is invoked > from the shell, and (b) when cygrunsrv installs the services, it adds /bin > to the PATH in the service environment. Which is too late for cygrunsrv itself, right? The idea is to avoid having to add the Cygwin bin dir to the system variable %PATH%. If you want to accomplish that, cygrunsrv itself must be independent of it. That's only the case if it shares the bin dir with the Cygwin DLL. > > Right now I must admit that I prectically don't care if my packages > > install the binaries in /bin or /usr/bin. > > /bin should contain programs that should work even if the PATH and mounts > are screwed up. So, "kill", "shutdown", etc. And cygrunsrv. > > However, that's not really necessary anymore with /etc/fstab. > > So I agree, we can simply get rid of fstab.$SID. > > Yes, that reasoning is mostly correct. However, some packages (like > Cygwin/X) apparently assume a single-user installation, and create > sockets/temp files in shared locations (i.e., /tmp). That, unfortunately, That's a bug in Cygwin/X or in using it. If you have different DISPLAY numbers for different displays, they shouldn't share the /tmp stuff, just like on Linux et al. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat