This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

1.5 / 1.7 setup.exe entanglement?


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]