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 >> >user. >> >> So you're advocating that the Cygwin web site should start using >> javascript? > >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. AFAIK, javascript is required for this to be foolproof. >> >> 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[0] 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 sense. >> 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 >accident? 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. > >So, C:\cygwin64? > >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? cgf
