Gearing up for Final - new fake installers for testing

[Jon]

As part of our push for a RubyInstaller Final release, please take a few moments to test out the latest FakeRubyInstaller's in a variety of different situations:

http://tinyurl.com/yzj2jm2

http://tinyurl.com/ykf6bvv

http://tinyurl.com/yhopnpx

The most notable installer modifications from RC2 are:

* updated default install directory (user changeable) based upon the Ruby version to be installed. For example, c:\Ruby191

* new registry identification keys and values targeted to helping 3rd parties more easily integrate with the RubyInstaller. The RubyInstaller identification registry values will live under the {HKLM,HKCU}\Software\RubyInstaller\<RUBY_IMPLEMENTATION>\x.y.z keys, allowing for multiple versions of multiple Ruby implementations. For example, HKCU\Software\RubyInstaller\MRI\1.9.1

As always, code review and feedback is welcome and appreciated:

http://github.com/oneclick/rubyinstaller/compare/usability

Any other issues you strongly believe need to be addressed for Final?

Thanks,
Jon

[Stuart Ellis]

On 11 Mar 2010, at 16:34, Jon wrote:

> As part of our push for a RubyInstaller Final release, please take a few moments to test out the latest FakeRubyInstaller's in a variety of different situations:
>
> http://tinyurl.com/yzj2jm2
>
> http://tinyurl.com/ykf6bvv
>
> http://tinyurl.com/yhopnpx
>

> As always, code review and feedback is welcome and appreciated:
>
> http://github.com/oneclick/rubyinstaller/compare/usability
>

Hi,

Just to report a success - I've downloaded the installer from the first link and successfully installed it on Vista Business SP2 without issue. The Registry keys were put into HKCU.

I also installed with the /silent switch - also worked correctly.

---
Stuart Ellis
stu...@stuartellis.eu

[Jon]

> Just to report a success - I've downloaded the installer from the first link and successfully installed it on Vista Business SP2 without issue. The Registry keys were put into HKCU.
>
> I also installed with the /silent switch - also worked correctly.
>
> ---
> Stuart Ellis

Hi, welcome, and thanks for the testing and feedback!

Jon

[Jon]

Has anyone tried installing to a subdir of "C:\Program Files" yet?

On Vista and above I expect this to require one to explicitly right-
click-the-installer-and-run-as-administrator due to Vista's UAC and
protected folder behavior. I haven't yet upgraded to Win7 so I
haven't been able to test this scenario to confirm.

Thanks, Jon

[Charles Roper]

On 18/03/2010 20:04, Jon wrote:
> Has anyone tried installing to a subdir of "C:\Program Files" yet?

Just tried it on Vista.

> On Vista and above I expect this to require one to explicitly right-
> click-the-installer-and-run-as-administrator due to Vista's UAC and
> protected folder behavior.

Yes, that is the case. If you run without elevation, you get this:

http://i.imgur.com/uCXbI.png

Charles

[Bosko Ivanisevic]

Neither have I but on Windows XP x64 Professional everything works
fine.

Regards,
Bosko

[Octagon]

> Neither have I but on Windows XP x64 Professional everything works
> fine.

Neither have I and will never do. On Vista and above, that which
installs itself
into a protected folder does so in order to enjoy the protection.
Among other
things, this means that it does not use the protected folder to store
any kind
of data, like gems, temporary files, whatever.

Vista and above provides the Virtual Storage work around for programs
that are
not Vista aware (that is, do not have a manifest), and do not run with
elevated
privileges (please note that elevated privileges are not exactly
equivalent to
"As Administrator", especially on 7 with its silent privileges
escalation mechanism,
thus providing very interesting corner cases), but write to a
protected folder.

This Virtual Storage works OK in most cases, is guaranteed to create
problems
if something is run with both normal and elevated privileges (like an
installer and
normal operation) and should be avoided whenever possible.

I guess it is pointless to make anything ported from Linux fully
Windows, like
adding manifests to _everything_ and putting all kinds of storage to a
separate
location. My guess is that installing Ruby to a protected folder
should be just
officially unsupported.

[Jon]

> On Vista and above, that which installs itself into a protected folder
> does so in order to enjoy the protection. Among other things, this means
> that it does not use the protected folder to store any kind of data,
> like gems, temporary files, whatever.
>

> ...SNIP...

>
> This Virtual Storage works OK in most cases, is guaranteed to create
> problems if something is run with both normal and elevated privileges
> (like an installer and normal operation) and should be avoided whenever
> possible.

Agree. These reasons (in addition to generally disliking pathnames with spaces) are the reasons I will *never* install to Program Files.

While I think our installer's current behavior is correct, I'd like to see a bit more test results on installs to "C:\Program Files" to see how regular gem install/uninstalls and DevKit built native gems behave.

I suspect it will be a mess, but we need to validate. OTH, maybe AppData\Local\VirtualStore virtualization works just fine for this scenario.

It's on my TODO list to confirm, but I'm slow getting to it :( Would be great if someone with a few moments would test and reply with their results.

> My guess is that installing Ruby to a protected folder should be just officially unsupported.

I agree, if testing confirms it's an ugly mess for gems and DevKit builds. Luis?

Jon

[Luis Lavena]

On Fri, Mar 19, 2010 at 2:25 PM, Jon <jon.f...@gmail.com> wrote:
>
>
>> My guess is that installing Ruby to a protected folder should be just officially unsupported.
>
> I agree, if testing confirms it's an ugly mess for gems and DevKit builds.  Luis?
>

Ruby never worked right with path with spaces, MSYS completely dislikes it.

Combine that with Elevation, Virtual Storage and all that, the
installation in a folder like Program Files is completely unsupported
and advised against it.

That is one of the reasons the installer default to SystemDrive \ RubyXYZ
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

[Jon]

> >> My guess is that installing Ruby to a protected folder should be just officially unsupported.
> >
> > I agree, if testing confirms it's an ugly mess for gems and DevKit builds.  Luis?
> >
>
> Ruby never worked right with path with spaces, MSYS completely dislikes it.
>
> Combine that with Elevation, Virtual Storage and all that, the
> installation in a folder like Program Files is completely unsupported
> and advised against it.

I'll create a FAQ entry on our GitHub wiki.

I still want to see the (a) normal gem install/uninstall, and (b) DevKit native build test results so we know *exactly* how things behave.

Jon

[Luis Lavena]

I'm going to put my results on sunday with some output on how these
errors looks like

BTW: there is a troubleshooting page now:

http://wiki.github.com/oneclick/rubyinstaller/troubleshooting

[Jon]

> > I still want to see the (a) normal gem install/uninstall, and (b) DevKit native build test results so we know *exactly* how things behave.
> >
>
> I'm going to put my results on sunday with some output on how these
> errors looks like
>
> BTW: there is a troubleshooting page now:
>
> http://wiki.github.com/oneclick/rubyinstaller/troubleshooting

Great!

How about using a similar style to http://wiki.github.com/oneclick/rubyinstaller/faq where we have link summaries at the top of the page that take you to the details below?

This style will be easier to use as the troubleshooting page gets bigger...you don't have to scroll through everything to get to what you're looking for.

The textile formatting is pretty simple...edit the faq page to see, but it looks something like:

* "When compiling gems, it complained...":#missing_hdr

...

h4(#missing_hdr). When compiling gems, it complained...

Blah, blah, blah description