chocolateyUpdate.ps1

[silbermm]

Does chocolatey support an update script like chocolateyInstall.ps1 or chocolateyUninstall.ps1?

[ferventcoder]

Would you put this in the old package or the new package?

On Tuesday, May 14, 2013, Matt Silbernagel wrote:

Does chocolatey support an update script like chocolateyInstall.ps1 or
chocolateyUninstall.ps1?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/291
.

---

Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[silbermm]

I would think the new package. Specifically, I'm creating a package that runs a service. When I update it, the service will need to stop as to free up all the resources.

[ferventcoder]

What if you change the name of the service? Only the old service should
know that name, itherwise it gets messy. Or is that an uninstall concern?
Whats the difference between uninstall and upgrade?

On Tuesday, May 14, 2013, Matt Silbernagel wrote:

I would think the new package. Specifically, I'm creating a package that
runs a service. When I update it, the service will need to stop as to free
up all the resources.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/291#issuecomment-17904986
.

---

Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[ferventcoder]

Sorry meant whats difference between uninstall old version/install new
version versus upgrade? And by that I'm referring to end state.

On Tuesday, May 14, 2013, Matt Silbernagel wrote:

I would think the new package. Specifically, I'm creating a package that
runs a service. When I update it, the service will need to stop as to free
up all the resources.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/291#issuecomment-17904986
.

---

Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[silbermm]

So what your saying is that the install script should check for the service, stop it and then continue normally? I guess i didn't think about that, but should work.

Thanks

Rob Reynolds notifications@github.com wrote:

Sorry meant whats difference between uninstall old version/install new
version versus upgrade? And by that I'm referring to end state.

On Tuesday, May 14, 2013, Matt Silbernagel wrote:

I would think the new package. Specifically, I'm creating a package that
runs a service. When I update it, the service will need to stop as to free
up all the resources.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/291#issuecomment-17904986
.

---

Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/291#issuecomment-17913949.

[gep13]

When you said:

"I'm creating a package that runs a service"

I take it you mean a windows service? If so, how are you creating the service in the first place? Are you using something like WiX? If so, you can put the responsibility for stoppping/starting this service into the hands of the installation package, i.e. the MSI, and not worry about this within the chocolatey package.

Gary

[silbermm]

yes, that's correct, I'm creating a windows service. The installer I'm
using is InnoScript, but the service is actually created and started
using the Java Service Wrapper. So yes, I can put the responsibility on
the installer itself.

Thanks again for you help
On 05/15/13 at 05:49am, Gary Ewan Park wrote:

When you said:

"I'm creating a package that runs a service"

I take it you mean a windows service? If so, how are you creating the service in the first place? Are you using something like WiX? If so, you can put the responsibility for stoppping/starting this service into the hands of the installation package, i.e. the MSI, and not worry about this within the chocolatey package.

Gary

---

Reply to this email directly or view it on GitHub:
#291 (comment)

Matt Silbernagel
Computer and Information Analyst
Instructional and Research Computing
540D Langsam Library
513-556-9064

[gabisa]

IMO chocolatey update behavior has a BIG miss: excepting that it updates the package installation, it doesn't run the chocolateyUninstall.ps1 script for the installed package! If in the chocolateyInstall.ps1 some resources are created and in a higher version some of them are removed or renamed, the final result would be that after the upgrade, the resources will be represent the union (merge) of both versions instead of representing just the resources corresponding to the higher version.

Ex: At the installation time in the chocolateyInstall.ps1a folder / files stucture is created. In a higher package version, this structure is changed: some folder / files are kept, others are renamed and some are deleted. By updating, the result is the old folder / files structure merged with the new folder / files structure, which is wrong!

IMO, the correct behavior for the update in this situation is:

• if no same version detected - do nothing
• if a higher version is detected:
  • run the uninstall for the old version - execute the chocolateyUninstall.ps1 script (if exists)
  • run the install for the new version - execute the chocolateyInstall.ps1 script (if exists)

It is the responsibility of the scripts provider to correctly handle the resource manipulation during the uninstall/install.

I think that this way, both the initial issue in this thread and also the issue that I described in this post could be addressed. Unfortunately I don't see an easy way to answer these needs...

Any comments?

[ferventcoder]

By updating, the result is the old folder / files structure merged with the new folder / files structure, which is wrong!

Sometimes this is the result of the native installer not performing the upgrade correctly.

run the uninstall for the old version - execute the chocolateyUninstall.ps1 script (if exists)

While this appears to be a good solution, some uninstallers remove files you would want to keep around in an upgrade scenario. That's why we usually let the native installers that already know how to upgrade do their thing. In most times they handle the upgrade well, however there are cases where you mentioned artifacts are left behind. In the principal of least surprise, I would find it more surprising if files / configuration were missing versus some extra files/folders around.

Thoughts?

[gabisa]

It is ALWAYS the responsibility of the script provider to properly handle these operations correctly. The rest are exceptions and these faulty scripts should be fixed, as opposed to not executing the proper upgrade sequence.

I can imagine an other scenario in which "some" old files are left on "some" path and "some" faulty script could find and use them although it should not as new files are available... IMO this situation is at least as dangerous as yours...

I think that chocolatey has to follow the right sequence. In order to address your situation, some switch or customization could be added (and used only for those cases). Otherwise, the result would be similar with a "garbage collector" preventing serious applications to use it. I am currently estimating if this can suit our company's needs and apparently we cannot agree in this regard. We have our NuGet server, we handle just our packages and the scripts are ours. There is no reason why we cannot handle this legit situation properly while Chocolatey seems to care more about incorrect packages/installations...

[gabisa]

Actually I have an idea: a slightly changed copy of "cup" command that will execute the right sequence. The old one will stay as it is.

I also think that it is a miss in the documentation, as nowhere I could find if any of the scripts are executed and when. All my deductions were based on tries and searching the net...

What do you think?

[jberezanski]

@gabisa:

IMO, the correct behavior for the update in this situation is:
•if no same version detected - do nothing
•if a higher version is detected: ◦run the uninstall for the old version - execute the chocolateyUninstall.ps1 script (if exists)
◦run the install for the new version - execute the chocolateyInstall.ps1 script (if exists)

I'm afraid that won't do in the general case.

Most nontrivial programs create and keep some state that needs to be preserved when upgrading, but removed when uninstalling: configuration, log files etc. Simply running "uninstall" and "install", without any sort of cooperation between these two, would destroy that state.

In addition, an intelligent update (e.g. MSI) could only perform the adjustments necessary to bring the installed software up to the latest version, potentially reducing the time needed to perform the update and minimizing the disturbance to the system.

Therefore, the scripts and installers need to be aware that they are invoked in an update scenario, so that they are able to act appropriately.

I see two solutions:

1. Introduce the "chocolateyUpdate.ps1" script mentioned in the title, which should be placed in the newer package (the newer version knows about older versions, but not the other way around). Chocolatey should call that script if it exists (and skip chocolateyUninstall.ps1 from the existing, older package), otherwise fall back to uninstall old + install new.
2. Add parameter(s) to chocolateyInstall.ps1 and chocolateyUninstall.ps1 to make them aware that they are being called in an update scenario. (Not a fan of this one, because it would complicate those scripts.)

[ferventcoder]

1. Introduce the "chocolateyUpdate.ps1" script mentioned in the title, which should be placed in the newer package (the newer version knows about older versions, but not the other way around). Chocolatey should call that script if it exists (and skip chocolateyUninstall.ps1 from the existing, older package), otherwise fall back to uninstall old + install new.

And this chocolateyUpdate.ps1 could call the older package's uninstall should the maintainer know the ramifications of this.

[rismoney]

Have you thought about - #160 (comment)
and using Update {}

Then just call that file chocolateyPackage.ps1

[ferventcoder]

Will be thinking of improvements we can make as we move forward on the new version.

[jberezanski]

@ferventcoder:

And this chocolateyUpdate.ps1 could call the older package's uninstall should the maintainer know the ramifications of this.

Precisely. The version and path to the package being upgraded could be passed to the update script as parameters, making it really easy.

@rismoney: That would work, too. However, switching to the single file model brings with itself the challenge of reeducating package maintainers and possibly converting existing packages.

[gabisa]

I solved my case by doing an unconditional uninstall followed by an install. I know, this will always download and install the package but it's ok for us.

Thanks everybody for being involved and trying to help! Hopefully chocolatey will be able someday to directly handle an update for a normal situation in which both install and uninstall are properly designed,
especially when you deal with your own packages and your own NuGet server...

[ferventcoder]

Migrated to chocolatey/choco#268