X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_20 X-Spam-Check-By: sourceware.org Message-ID: <49779B20.9060905@etr-usa.com> Date: Wed, 21 Jan 2009 15:01:04 -0700 From: Warren Young User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Cygwin-L Subject: 1.5 / 1.7 setup.exe entanglement? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com I got a new machine at work a few weeks ago, and decided to install Cygwin 1.7 on it, and not even mess with 1.5. Can't test what you don't use, right? For reasons that aren't important here, today I decided I needed a copy of 1.5 as well. This means I have the reverse of the recommended setup, which is having 1.5 installed in c:\cygwin, and 1.7 elsewhere. 1.7 on my machine is in c:\cygwin, and 1.5 is in c:\cygwin-1.5. The installation of 1.5 failed in several ways. The way it failed makes me wonder if some part of the setup process was erroneously referring to stuff in c:\cygwin instead of c:\cygwin-1.5. The first weird thing is that the first time I ran 1.5's setup.exe on this machine, "Local Package Directory" on the fourth page of setup.exe defaulted to my Cygwin 1.7 download directory. On a fresh machine, I thought this value defaulted to the location of setup.exe. How did it find this other location if not by peeking into c:\cygwin or 1.7's registry keys? On subsequent runs, 1.5's setup.exe did have the correct location for this value. This makes me think it's storing the location separately for each version, but that doesn't explain everything. More seriously, the resulting setup did not contain bash.exe, cygreadline6.dll, or cygncurses-8.dll. On re-running setup.exe to install bash.exe -- the first thing I noticed missing -- the postinstall scripts all failed to run due to the DLLs missing. Apparently setup.exe just quietly ate the errors to launch the postinstall scripts due to missing bash. I had to go back through setup.exe a few times fighting past the postinstall errors to get the DLLs sorted out. Once I did, all the postinstall scripts ran as expected. Another thing that leads me to believe setup.exe for 1.5 is seeing things in my 1.7 install that it shouldn't is that a lot more things got installed than I thought was in Cygwin 1.5 base. I didn't select any optional packages...I just wanted a basic 1.5 installation for testing. I got things like Python and X, which I installed under 1.7 knowingly. My theory is that all of these latter problems are due to 1.5's setup.exe looking at the package list in 1.7 erroneously. This would explain why it thought it didn't need to install bash, libreadline, or libncurses -- it thought they were up to date. It also explains why it pulled in all those other packages, because it thought I wanted them. I'm not sure how much this matters right now. I freely acknowledge I'm doing something a little weird here. I just wonder, if I'm right about this and it isn't fixed, what will happen when more people start installing 1.7 by default, but install 1.5 beside it later for backwards compatibility testing. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/