This is the mail archive of the cygwin-apps 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]

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
>> >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


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