1.4.0RC2 windows installer feedback

[Jon M]

Ran an install/uninstall cycle on a Vista SP2 Home Premium using an Administrator account.

Anyone else seeing the following?

* Start menu has just JRuby menu item.  Would be nice to have JRuby version info in the menu name.
* JRuby 1.4.0RC1 (incorrect version) appears in uninstall menu.  Installer script typo?
* Places uninstall info into HKLM but updates PATH in HKCU.  Should the info be in the same hive dependent upon user account type?
* Leaves behind HKCU\Software\ej-technologies\exe4j key and its subkeys and values
* Leaves behind HKLM\Software\ej-technologies\install4j\installations key
* Destination selection dir incorrectly defaults to "C:\Program Files\jruby-1.4.0RC1" and uninstaller leaves behind HKCU\Software\ej-technologies\exe4j\pids with a "c:\program files\jruby-1.4.0rc1\uninstall.exe".  Installer script typo?

Any way to kick install4j into shape and have it fully clean itself from the registry upon uninstall?

Jon

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Nick Sieger-2]

On Oct 22, 2009, at 13:22 , Jon wrote:

> Ran an install/uninstall cycle on a Vista SP2 Home Premium using an  
> Administrator account.
>
> Anyone else seeing the following?
>
> * Start menu has just JRuby menu item.  Would be nice to have JRuby  
> version info in the menu name.
> * JRuby 1.4.0RC1 (incorrect version) appears in uninstall menu.  
> Installer script typo?
> * Places uninstall info into HKLM but updates PATH in HKCU.  Should  
> the info be in the same hive dependent upon user account type?
> * Leaves behind HKCU\Software\ej-technologies\exe4j key and its  
> subkeys and values
> * Leaves behind HKLM\Software\ej-technologies\install4j
> \installations key
> * Destination selection dir incorrectly defaults to "C:\Program Files
> \jruby-1.4.0RC1" and uninstaller leaves behind HKCU\Software\ej-
> technologies\exe4j\pids with a "c:\program files
> \jruby-1.4.0rc1\uninstall.exe".  Installer script typo?
>
> Any way to kick install4j into shape and have it fully clean itself  
> from the registry upon uninstall?

This is good feedback about the installer, thanks. I think we should  
fix. Would you mind filing a bug with this info at http://jira.codehaus.org/browse/JRUBY?

/Nick

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Thomas E Enebo]

On Thu, Oct 22, 2009 at 1:22 PM, Jon <jon.forums@...> wrote:
> Ran an install/uninstall cycle on a Vista SP2 Home Premium using an Administrator account.
>
> Anyone else seeing the following?
>
> * Start menu has just JRuby menu item.  Would be nice to have JRuby version info in the menu name.

We are adding jruby and jirb as items for final release.

Adding version to the name is a very good idea.

> * JRuby 1.4.0RC1 (incorrect version) appears in uninstall menu.  Installer script typo?

This is already reported and being worked on.

> * Places uninstall info into HKLM but updates PATH in HKCU.  Should the info be in the same hive dependent upon user account type?
> * Leaves behind HKCU\Software\ej-technologies\exe4j key and its subkeys and values
> * Leaves behind HKLM\Software\ej-technologies\install4j\installations key
> * Destination selection dir incorrectly defaults to "C:\Program Files\jruby-1.4.0RC1" and uninstaller leaves behind HKCU\Software\ej-technologies\exe4j\pids with a "c:\program files\jruby-1.4.0rc1\uninstall.exe".  Installer script typo?
>
> Any way to kick install4j into shape and have it fully clean itself from the registry upon uninstall?

We should be able to do something to remove these extra unused keys.
Can you file an issue on this for us for removing unused keys during
uninstall:
http://jira.codehaus.org/browse/JRUBY

-Tom



--
blog: http://blog.enebo.com       twitter: tom_enebo
mail: tom.enebo@...

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jon M]

On Thu, 22 Oct 2009 13:24:45 -0500
Nick Sieger <nicksieger@...> wrote:

> On Oct 22, 2009, at 13:22 , Jon wrote:
>
> > Ran an install/uninstall cycle on a Vista SP2 Home Premium using an  
> > Administrator account.
> >
> > Anyone else seeing the following?
> >
> > * Start menu has just JRuby menu item.  Would be nice to have JRuby  
> > version info in the menu name.
> > * JRuby 1.4.0RC1 (incorrect version) appears in uninstall menu.  
> > Installer script typo?
> > * Places uninstall info into HKLM but updates PATH in HKCU.  Should  
> > the info be in the same hive dependent upon user account type?
> > * Leaves behind HKCU\Software\ej-technologies\exe4j key and its  
> > subkeys and values
> > * Leaves behind HKLM\Software\ej-technologies\install4j
> > \installations key
> > * Destination selection dir incorrectly defaults to "C:\Program Files
> > \jruby-1.4.0RC1" and uninstaller leaves behind HKCU\Software\ej-
> > technologies\exe4j\pids with a "c:\program files
> > \jruby-1.4.0rc1\uninstall.exe".  Installer script typo?
> >
> > Any way to kick install4j into shape and have it fully clean itself  
> > from the registry upon uninstall?
>
> This is good feedback about the installer, thanks. I think we should  
> fix. Would you mind filing a bug with this info at http://jira.codehaus.org/browse/JRUBY?
>
> /Nick

I want to finish some of the following paranoid corner case tests before filing something...

* Handles pre-existing, but empty, PATH value by not deleting PATH value upon uninstall?
* Handles non-existing PATH value by deleting installer created PATH value upon uninstall?
* Handles pre-existing JRuby bindir on PATH by not creating 2 bindir entries on install, and not deleting the pre-existing bindir PATH entry on uninstall?
* Handles post-JRuby-install swizzling of JRuby bindir position on PATH (i.e. - user installs something afterwards that updates PATH) by not assuming JRuby bindir will always be at front of PATH?

Jon

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Vladimir Sizikov-2]

Hi Jon,

Terrific questions! It looks like you've been doing lots of testing in
your life, eh? :)

Thanks,
  --Vladimir

On Thu, Oct 22, 2009 at 8:35 PM, Jon <jon.forums@...> wrote:
> I want to finish some of the following paranoid corner case tests before filing something...
>
> * Handles pre-existing, but empty, PATH value by not deleting PATH value upon uninstall?
> * Handles non-existing PATH value by deleting installer created PATH value upon uninstall?
> * Handles pre-existing JRuby bindir on PATH by not creating 2 bindir entries on install, and not deleting the pre-existing bindir PATH entry on uninstall?
> * Handles post-JRuby-install swizzling of JRuby bindir position on PATH (i.e. - user installs something afterwards that updates PATH) by not assuming JRuby bindir will always be at front of PATH?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Peter Ritchie]

>> * Start menu has just JRuby menu item. �Would be nice to have JRuby version info in the menu name.
>
> We are adding jruby and jirb as items for final release.

also nice might be "jruby command prompt" (has jruby's bin path in
command path).
-r
--
Posted via http://www.ruby-forum.com/.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Trejkaz-3]

On Fri, Oct 23, 2009 at 10:37 AM, Roger Pack <lists@...> wrote:
>
> also nice might be "jruby command prompt" (has jruby's bin path in
> command path).

Why are you still using cmd.exe?  You should be using rush!  :-D

TX

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Aaron McLeod]

havent heard of rush. I use console2 for a nice wrapper for cmd. Have tabs and all that. Still cant really hi-light sections of the output like in linux though.

On Fri, Oct 23, 2009 at 12:50 AM, Trejkaz <trejkaz@...> wrote:

On Fri, Oct 23, 2009 at 10:37 AM, Roger Pack <lists@...> wrote:
>
> also nice might be "jruby command prompt" (has jruby's bin path in
> command path).

Why are you still using cmd.exe?  You should be using rush!  :-D

TX

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

--
Aaron McLeod
http://agmprojects.com

[Jon M]

Consider allowing the user to decide whether to update PATH via the GUI...something like

http://www.screencast.com/t/zezdKPtz

Makes it easier to have multiple JRuby's on your system, or maybe you've written a clever PATH switcher a la http://github.com/vertiginous/pik or maybe you're doing other things and want to explicitly manage your own PATH.

Jon

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Thomas E Enebo]

On Thu, Oct 22, 2009 at 1:22 PM, Jon <jon.forums@...> wrote:
> Ran an install/uninstall cycle on a Vista SP2 Home Premium using an Administrator account.
>
> Anyone else seeing the following?
>
> * Start menu has just JRuby menu item.  Would be nice to have JRuby version info in the menu name.

This has been fixed and will show up in next RC.

> * JRuby 1.4.0RC1 (incorrect version) appears in uninstall menu.  Installer script typo?

Also fixed.

> * Places uninstall info into HKLM but updates PATH in HKCU.  Should the info be in the same hive dependent upon user account type?
> * Leaves behind HKCU\Software\ej-technologies\exe4j key and its subkeys and values
> * Leaves behind HKLM\Software\ej-technologies\install4j\installations key

Jon,  I can certainly understand wanting the system in the same state
as it was before the install, but I am a little concerned about wiping
out these keys.  If install4j and exe4j were already used by another
installed product and I blindly wiped these out wouldn't I cause harm
to those other installed products (for example, I can see an Azureus
entry in mine)?  Shouldn't install4j be a good citizen here versus
every installer consumer?  Still hoping to figure out a way to ask
install4j to clean up after itself.

I am trying to figure out how the product manages these things, but I
am not well versed in windows and working with registry keys so I am
not sure how much time I can spend on this.  Part of the decision to
use install4j is that it seemed like a product which should just do
the right things.  The uninstall in HKLM and the PATH in HKCU seems
wrong, but the path in HKCU is largely one check box ('User
Specific').  The fact that the uninstall info gets put into HKLM seems
like it is just what install4j does.  As far as I can tell?

> * Destination selection dir incorrectly defaults to "C:\Program Files\jruby-1.4.0RC1" and uninstaller leaves behind HKCU\Software\ej-technologies\exe4j\pids with a "c:\program files\jruby-1.4.0rc1\uninstall.exe".  Installer script typo?

Fixed I think.  It still seems to contain every key from every version
ever installed, but my new versioned one is in there as well.  Seems
like it does not clean out entries in here.

> Any way to kick install4j into shape and have it fully clean itself from the registry upon uninstall?

That's the million dollar question.  I think most of the non-registry
problems have been solved though.

-Tom

--
blog: http://blog.enebo.com       twitter: tom_enebo
mail: tom.enebo@...

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jon M]

> > * Places uninstall info into HKLM but updates PATH in HKCU.  Should the info be in the same hive dependent upon user account type?
> > * Leaves behind HKCU\Software\ej-technologies\exe4j key and its subkeys and values
> > * Leaves behind HKLM\Software\ej-technologies\install4j\installations key
>
> Jon,  I can certainly understand wanting the system in the same state
> as it was before the install, but I am a little concerned about wiping
> out these keys.  If install4j and exe4j were already used by another
> installed product and I blindly wiped these out wouldn't I cause harm
> to those other installed products (for example, I can see an Azureus
> entry in mine)?  Shouldn't install4j be a good citizen here versus
> every installer consumer?  Still hoping to figure out a way to ask
> install4j to clean up after itself.

Tom, yeh that's the tough one and quickly leads down the rabbit hole.

FWIW, I'm revamping the Inno-based installer for http://rubyinstaller.org and have just pushed out test installers and the code to implement what I call "nano system restore" for the key areas of the registry that the installer mucks with.  Specifically, PATH, PATHEXT, and the .RB/.RBW file associations.  In a nutshell, the nano system restore code takes a snapshot of certain parts of the system *before* installation, caching relevant values in the registry.  Upon uninstall it restores from the cache in order to bring the system back to the original state.  The caches are namespaced in the registry so that one can install multiple versions and not have the snapshot/restore code make a mess of things.

This all sounds too good to be true I know, and we're trying to run the code through the gauntlet to confirm that it works and it doesn't try to do more than it needs to.  I'd appreciate more eyes looking over code, and it would be great if any of it could help with your efforts.

The code is MIT licensed at http://github.com/jonforums/rubyinstaller/tree/installer/resources/installer/ if you'd like to look it over.  I've also made test installers available at http://www.mediafire.com/jonforums that you can run through a bunch of weird scenarios (hopefully in a VM) to see how well it plays with pre-existing systems.  The "fake installers" only install a few placeholder files, add some Start Menu links, and setup things for clean uninstalls.

The key files to look at are "rubyinstaller-fake.iss" (starting at line 151) and "util.iss" which does the heavy lifting.

The key downside is that the code is in Delphi/Pascal (ugh!!) which I learned along the way...so I'm sure it's highly Delphi idiomatic.  However, it should be easy to port to whatever install4j uses, but I still don't envy anyone using that language.

If you do find any of it useful, the only thing I ask is that you let me know where the code falls down and what you think needs to be fixed in order to be more bullet proof.

Installer's really are the Root of All Evil until they prove themselves otherwise >;->


> I am trying to figure out how the product manages these things, but I
> am not well versed in windows and working with registry keys so I am
> not sure how much time I can spend on this.  Part of the decision to
> use install4j is that it seemed like a product which should just do
> the right things.  The uninstall in HKLM and the PATH in HKCU seems
> wrong, but the path in HKCU is largely one check box ('User
> Specific').  The fact that the uninstall info gets put into HKLM seems
> like it is just what install4j does.  As far as I can tell?


For Standard users, I think you want to ensure everything goes under HKCU and for Administrator/Power users you *may* want to have everything under HKLM.  I think you're going to get a bunch of bugs filed if Standard users can't install (due to the HKCU/HKLM split) because their system is locked down and they can't authenticate as an Administrator.

Jon

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Thomas E Enebo]

On Sat, Oct 24, 2009 at 12:46 PM, Jon <jon.forums@...> wrote:

>> > * Places uninstall info into HKLM but updates PATH in HKCU.  Should the info be in the same hive dependent upon user account type?
>> > * Leaves behind HKCU\Software\ej-technologies\exe4j key and its subkeys and values
>> > * Leaves behind HKLM\Software\ej-technologies\install4j\installations key
>>
>> Jon,  I can certainly understand wanting the system in the same state
>> as it was before the install, but I am a little concerned about wiping
>> out these keys.  If install4j and exe4j were already used by another
>> installed product and I blindly wiped these out wouldn't I cause harm
>> to those other installed products (for example, I can see an Azureus
>> entry in mine)?  Shouldn't install4j be a good citizen here versus
>> every installer consumer?  Still hoping to figure out a way to ask
>> install4j to clean up after itself.
>
> Tom, yeh that's the tough one and quickly leads down the rabbit hole.
>
> FWIW, I'm revamping the Inno-based installer for http://rubyinstaller.org and have just pushed out test installers and the code to implement what I call "nano system restore" for the key areas of the registry that the installer mucks with.  Specifically, PATH, PATHEXT, and the .RB/.RBW file associations.  In a nutshell, the nano system restore code takes a snapshot of certain parts of the system *before* installation, caching relevant values in the registry.  Upon uninstall it restores from the cache in order to bring the system back to the original state.  The caches are namespaced in the registry so that one can install multiple versions and not have the snapshot/restore code make a mess of things.
>
> This all sounds too good to be true I know, and we're trying to run the code through the gauntlet to confirm that it works and it doesn't try to do more than it needs to.  I'd appreciate more eyes looking over code, and it would be great if any of it could help with your efforts.
>
> The code is MIT licensed at http://github.com/jonforums/rubyinstaller/tree/installer/resources/installer/ if you'd like to look it over.  I've also made test installers available at http://www.mediafire.com/jonforums that you can run through a bunch of weird scenarios (hopefully in a VM) to see how well it plays with pre-existing systems.  The "fake installers" only install a few placeholder files, add some Start Menu links, and setup things for clean uninstalls.

Cool.  I will take a look and see how we can integrate stuff.  It is
likely that we won't have a great installer for 1.4 final, but at
least we fixed a few of the issues.  Also we now at least have an
installer, which for us is a huge improvement in itself.

> The key files to look at are "rubyinstaller-fake.iss" (starting at line 151) and "util.iss" which does the heavy lifting.
>
> The key downside is that the code is in Delphi/Pascal (ugh!!) which I learned along the way...so I'm sure it's highly Delphi idiomatic.  However, it should be easy to port to whatever install4j uses, but I still don't envy anyone using that language.
>
> If you do find any of it useful, the only thing I ask is that you let me know where the code falls down and what you think needs to be fixed in order to be more bullet proof.

Will do.  Thanks for giving us heads up on issues that we can run into
with an installer and advice on things...

> Installer's really are the Root of All Evil until they prove themselves otherwise >;->
>
>
>> I am trying to figure out how the product manages these things, but I
>> am not well versed in windows and working with registry keys so I am
>> not sure how much time I can spend on this.  Part of the decision to
>> use install4j is that it seemed like a product which should just do
>> the right things.  The uninstall in HKLM and the PATH in HKCU seems
>> wrong, but the path in HKCU is largely one check box ('User
>> Specific').  The fact that the uninstall info gets put into HKLM seems
>> like it is just what install4j does.  As far as I can tell?
>
>
> For Standard users, I think you want to ensure everything goes under HKCU and for Administrator/Power users you *may* want to have everything under HKLM.  I think you're going to get a bunch of bugs filed if Standard users can't install (due to the HKCU/HKLM split) because their system is locked down and they can't authenticate as an Administrator.

Yeah I am going to make this install the program group for just the
current user.  We can perhaps add a checkbox for system install.  I
suspect this is something install4j can do with their standard install
screens (seems like a common usecase).

-Tom

--
blog: http://blog.enebo.com       twitter: tom_enebo
mail: tom.enebo@...

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jon M]

> Cool.  I will take a look and see how we can integrate stuff.  It is
> likely that we won't have a great installer for 1.4 final, but at
> least we fixed a few of the issues.  Also we now at least have an
> installer, which for us is a huge improvement in itself.

It's cool you've got an installer, and it looks pretty good to me.  I'm also glad you're not allowing an installer to block a release.  Of course, I'm a Luddite and just need a .7z for a binary to be happy.


> > For Standard users, I think you want to ensure everything goes under HKCU and for Administrator/Power users you *may* want to have everything under HKLM.  I think you're going to get a bunch of bugs filed if Standard users can't install (due to the HKCU/HKLM split) because their system is locked down and they can't authenticate as an Administrator.
>
> Yeah I am going to make this install the program group for just the
> current user.  We can perhaps add a checkbox for system install.  I
> suspect this is something install4j can do with their standard install
> screens (seems like a common usecase).

Makes sense.

I'm back in the land of the living after 5 days of being flattened by the flu.  I hope to find time to do a bit more testing as a Standard user and with silent installs as well as take a quick look over what's already in place wrt install4j.  How do I get involved with the install4j stuff?


Jon

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Thomas E Enebo]

On Thu, Oct 29, 2009 at 1:50 PM, Jon <jon.forums@...> wrote:

>> Cool.  I will take a look and see how we can integrate stuff.  It is
>> likely that we won't have a great installer for 1.4 final, but at
>> least we fixed a few of the issues.  Also we now at least have an
>> installer, which for us is a huge improvement in itself.
>
> It's cool you've got an installer, and it looks pretty good to me.  I'm also glad you're not allowing an installer to block a release.  Of course, I'm a Luddite and just need a .7z for a binary to be happy.
>
>
>> > For Standard users, I think you want to ensure everything goes under HKCU and for Administrator/Power users you *may* want to have everything under HKLM.  I think you're going to get a bunch of bugs filed if Standard users can't install (due to the HKCU/HKLM split) because their system is locked down and they can't authenticate as an Administrator.
>>
>> Yeah I am going to make this install the program group for just the
>> current user.  We can perhaps add a checkbox for system install.  I
>> suspect this is something install4j can do with their standard install
>> screens (seems like a common usecase).
>
> Makes sense.
>
> I'm back in the land of the living after 5 days of being flattened by the flu.  I hope to find time to do a bit more testing as a Standard user and with silent installs as well as take a quick look over what's already in place wrt install4j.  How do I get involved with the install4j stuff?

If you have install4j installed you can then use our Rakefile to build
it ('rake installer'). The path is defined in default.build.properties
if you are not on a mac.  You will also need 'ant' installed (version
1.7+) to be able to fully build our source.  The final bit is an
evaluation key which I believe you get free for a month to play with
install4j.

The install4j screens are extremely packed full of stuff and it saves
to an XML file (which can be directly modified if you understand what
everything is for).

-Tom

--
blog: http://blog.enebo.com       twitter: tom_enebo
mail: tom.enebo@...

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jon M]

> If you have install4j installed you can then use our Rakefile to build
> it ('rake installer'). The path is defined in default.build.properties
> if you are not on a mac.  You will also need 'ant' installed (version
> 1.7+) to be able to fully build our source.  The final bit is an
> evaluation key which I believe you get free for a month to play with
> install4j.

Thanks, dependencies not an issue.

For the future, you may want to create a mini-installer that allows you to tweak/test installer functionality/GUI without requiring a full source build.  May not be worth the effort...once you're "done" with the installer, you're not likely to want to regularly tweak it.

The eval key isn't pleasant.  I Understand though and I'll check it out.  You may want to look again at http://izpack.org/features/ although it requires a JVM to already be installed.

Jon

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Thomas E Enebo]

On Fri, Oct 30, 2009 at 10:49 AM, Jon <jon.forums@...> wrote:

>> If you have install4j installed you can then use our Rakefile to build
>> it ('rake installer'). The path is defined in default.build.properties
>> if you are not on a mac.  You will also need 'ant' installed (version
>> 1.7+) to be able to fully build our source.  The final bit is an
>> evaluation key which I believe you get free for a month to play with
>> install4j.
>
> Thanks, dependencies not an issue.
>
> For the future, you may want to create a mini-installer that allows you to tweak/test installer functionality/GUI without requiring a full source build.  May not be worth the effort...once you're "done" with the installer, you're not likely to want to regularly tweak it.

Yeah that is true...There are some files the installer expects to be
there so at least on ant dist is needed so it does not complain about
missing files.  However to speed things up (on master not 1.4 branch),
there is the following guard:

  ant "dist" unless ENV['TESTING_INSTALLER']

So if you 'jrake installer TESTING_INSTALLER=true' and you have at
some point run a dist once, then you can just run the installer.  This
stuff is still pretty messy because we are slowly getting ready to
move as much out of our ant files and push them into our Rakefile.
Just haven't quite gotten there yet.

-Tom

>
> The eval key isn't pleasant.  I Understand though and I'll check it out.  You may want to look again at http://izpack.org/features/ although it requires a JVM to already be installed.
>

I am guessing we could probably boil in a izpack+JRE manually using
whatever logic izpack allows, so it is worth checking out.  We also
want to put out linux + macOS installers so we are always keeping our
eyes open.

-Tom


--
blog: http://blog.enebo.com       twitter: tom_enebo
mail: tom.enebo@...

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email