This is the mail archive of the
mailing list for the Cygwin project.
Re: [PATCH] setup: port to 64-bit, part 1
On Mon, Mar 04, 2013 at 05:52:20PM +0100, Corinna Vinschen wrote:
>On Mar 4 11:10, Christopher Faylor wrote:
>> On Mon, Mar 04, 2013 at 11:32:36AM +0100, Corinna Vinschen wrote:
>> >A web based solution is also easier to change. If it turns out that the
>> >information we give to the users is bad, wrong, too short, too dumb, we
>> >can easily change the web page. Having to patch the installer and to
>> >reinstall them just to change the information provided to the user
>> >sounds rather awkward.
>> I don't see why there would be major rewording needed, but if there is,
>> then I'm comfortable rerolling setup.exe and uploading it. While it
>> isn't as simple as modifying a web page and typing "cvs commit", most of
>> my setup.exe building and uploading is fairly automated.
>Except that the changes aren't there and S still HTDI. Changing a web
>page is easier.
"Changes aren't there"? Sorry can't grok that. I'm not arguing that
changing a web page isn't easy. I think it is misleadingly vivid to
represent changing the program and uploading it as overly burdensome.
>> >The web page itself can check the version of the client OS and tell the
>> So you're advocating that the Cygwin web site should start using
>No. I'm no web designer, I don't know what's required to let the web
>site print a client version string. I assume there are also perl or
>python cgi scripts available on the net.
>> >> If we start to see a number of people complaining then I would be
>> >> certainly be convinced that a 64-bit setup.exe is needed. I don't think
>> >> we have to limit ourselves out of the gate for this, in my opinion,
>> >Limit? Being able to provide a 64 bit installer for a 64 bit distro is
>> >not "limiting" ourselves, it free's us. It allows to support even the
>> >(yet) corner cases. It's the professional thing to do and, again, it
>> >doesn't cost us anything. It's not *that* much work to build two new
>> >setup versions and upload them. We have to do for each new package in
>> >the distro in future anyway.
>> I think it is "professional" to provide information to the user at
>> install time. But the word "professional" is really not something that
>> can be argued.
>> "*that* much work" is a straw man. I never said it was "work" to upload
>> two different setup.exe's. My building and uploading is all automated
>> so I could easily do this.
>> >And there's another point which speaks for using a 64 bit installer for
>> >the 64 bit distro. 32 and 64 bit tools partially use different registry
>> >keys. For instamce, the installation key of the 64 bit installation
>> >will be stored in HKLM/Software/Cygwin, the 32 bit installer installs
>> >its setup key into HKLM/Software/Wow6432Node/Cygwin.
>> >And what if a user would like to have 32 and 64 bit installations
>> >installed in parallel? I, for one, will have to do that. With distinct
>> >32 and 64 bit installers, updating the two distros is easy. I simply
>> >start both of them, click through to the chooser page and update. With
>> >a single 32 bit setup, I would only have one "current" installation in
>> >HKLM/Software/Wow6432Node/Cygwin/setup, and updating that is easy. But
>> >then I have to restart setup and change the path in the root dir window.
>> >Every time anew. And that I will have to do for all my 64 bit test
>> >machines. This is not amusing.
>> This is another straw man. We're talking about a program here. It can
>> make decisions based on the name of its argv or with my previously
>> proposed command line arguments. So, if you name setup.exe ->
>> setup64.exe (which you apparently want to do anyway) it could default to
>> the 64-bit distro.
>Hmm. The HKLM/Software/Wow6432Node/Cygwin/setup key only contains
>a single path. You would have to add a new registry item or better,
>you default to HKLM/Software/Cygwin/setup when running as setup64.
Not sure what you're saying here. The program could do whatever makes
>> Or, it could display a dialog box listing the paths
>> to the installation and ask which you want. Or both.
>Oh please, not another dialog...
>Dunno about "straw man" arguments or not, I'm just trying to bring up
>the arguments which concern me.
It's a "straw man" because you're implying that the implementation will
be limited in such a way as to cause you problems and then you react
to your arbitrarily limited examples as if they were the only alternative.
>Here's another one: How do you make sure that nobody overwrites a 32
>bit installation with 64 bit packages and vice versa from setup by
You seem to be moving on to general potential problems with two
distributions since this would be an issue regardless of whether there
is a 64-bit version of setup or not.
>> I'd be ok with a compromise of having two versions of setup.exe
>> available where something named setup64.exe defaulted to installing the
>> 64-bit version and something named setup.exe defaulted to installing the
>> 32-bit version. But I'd like the Cygwin installer to be capable of
>> installing (or download only when pulling down 64-bit to a 32-bit
>> system) either and for it to have as much information available as
>> possible to inform the user as to their choice.
>> I think that putting the decisions at the point of installation will
>> make it more likely that people will try out the 64-bit version,
>> especially if we allow (and we should allow) dual installation.
>Still, SHTDI, and it sounds like much more work than adding some text to
>the web page.
>Anyway, I said it in my previous mail already: At least let us provide
>a 64 bit setup on the web site. The code is in place, it doesn't hurt.
I asked you a while ago if we should start setting up a 64-bit release
area and you said that it was really premature to do something like
that. Are you using this email exchange to suggest that it's time to
set up a 64-bit release area?