From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15041 invoked by alias); 22 Apr 2008 17:02:02 -0000 Received: (qmail 15031 invoked by uid 22791); 22 Apr 2008 17:02:01 -0000 X-Spam-Check-By: sourceware.org Received: from out1.smtp.messagingengine.com (HELO out1.smtp.messagingengine.com) (66.111.4.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 Apr 2008 17:01:44 +0000 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 5CB811013E0 for ; Tue, 22 Apr 2008 13:01:42 -0400 (EDT) Received: from web6.messagingengine.com ([10.202.2.215]) by compute1.internal (MEProxy); Tue, 22 Apr 2008 13:01:42 -0400 Received: by web6.messagingengine.com (Postfix, from userid 99) id 38B53192B1; Tue, 22 Apr 2008 13:01:42 -0400 (EDT) Message-Id: <1208883702.16526.1249279229@webmail.messagingengine.com> From: "Charles Wilson" To: cygwin-apps@cygwin.com Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface References: <1208879483.2504.1249265081@webmail.messagingengine.com> <480E0D46.D208DAAE@dessent.net> Subject: Re: [HEADSUP] Let's start a Cygwin 1.7 release area In-Reply-To: <480E0D46.D208DAAE@dessent.net> Date: Tue, 22 Apr 2008 17:02:00 -0000 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/msg00282.txt.bz2 On Tue, 22 Apr 2008 09:07:34 -0700, "Brian Dessent" said: > Charles Wilson wrote: > > > (1) we're talking about cygwin-1.7.x > > (2) Either > > (a) only one of those parallel instances is in use at a time, > > including installed services, > > or > > (b) all of those parallel instances have exactly the same version of > > the DLL > > Right, I don't think anyone is talking about having two trees in use > simultaneously. I just didn't want somebody searching the archives to think cygwin-1.7 officially supported lots of different cygwin1.dlls scattered all over the filesystem, all in use at the same time. It doesn't. > > (3) Even so, doing this is not officially supported (the current > > dual-installation "support" vis-a-vis cygwin-1.5.x and cygwin-1.7.x is > > (a) temporary and > > (b) intended for package maintainers only, in order to prepare the > > cygwin-1.7 packages -- and package maintainers generally know what > > they are doing and what the pitfalls of a dual/multiple installation > > are. > > At the moment this is quite experimental, yes; but I don't see any > reason why it would be a temporary arrangement. Once we get the changes > in setup.exe and 1.7 released, it will still be possible to keep > multiple parallel installs by just changing the root dir in setup to > select which one to install/update. Why would we want to prevent that > from working? Isn't this one of the desired payoffs of moving the mount > table out of the registry in the first place? I didn't say we would *break* it. There's a difference between "it happens to work" and "is a supported configuration". During the buildup to 1.7.0-release, it's going to be a de-facto "supported" configuration -- if there are problems, they'll need to be fixed so that maintainers can build 1.7 packages. (Although Corinna recommended using completely separate (possibly virtual) machines for 1.5 and 1.7). After that, it's probably caveat emptor. Right now, we can tell a user to run 'cygcheck -s -v -r' and point to "multiple cygwin dll's" and tell 'em to fix that first, PERIOD, unless they really know what they are doing. After the official 1.7.0 rollout, unless we really truly actually support simultaneous *use* of multiple cygwin trees -- which we do not and will not -- I don't want to support/debug/handhold multiple simultaneous *installations* of cygwin, either. Because it's way too easy to slide from simultaneous installation to simultaneous use unless you are very careful. During the transition, we *will* run into that problem -- but maintainers can be trusted to usually figure those problems out on their own. -- Chuck