[BUG] Upgrading does not remove the previous version

[rismoney]

If I cup package, it will leave behind the previous package lib.
The issue I believe is that we don't want to remove all previous versions on an upgrade, but rather the single previous by default. Let me walk through some scenarios-

example:
cinst ruby -version 1.8.7
cinst ruby -version 1.9.3
cup ruby

I should have ruby 1.8.7 and
ruby 2.0 after running cup.

Do you guys agree with that logic?
If I wanted all three versions, I would need to do a cinst ruby -version 2.0 otherwise it would say it was already installed.

Right now, update doesn't take a source and target version.
I should be able to do something like
cup ruby 2.0 -bump 1.8.7
if I wanted to purge 1.8.7 and install 2.0:
or
cup ruby 2.0 -bump all
if i only wanted 2.0 and purge 1.8.7 and 1.9.3

[ferventcoder]

what you mean is choco clean.

[ferventcoder]

We do not remove the previous version at all when a new version comes in by design. You can install two versions of ruby.

[ferventcoder]

You need to be explicit on installing ruby versions.

But what I think we are missing here is a bigger design.

Choco clean removes all older versions of packages except for those you have pinned.

So if you have 3 versions of ruby and you pin the latest and the first one behind it, when you clean, the one that is not pinned goes away (from the chocolatey lib, but not uninstalled yet).

The uninstall itself should be smarter about asking someone what they want to remove when there are multiple versions. Like the way ruby gems does it when you have multiple installs of a gem.

choco uninstall ruby

Do you want to remove:

 1. Ruby v1.8.6
 2. Ruby v1.8.7
 3. Ruby v1.9.2
 4. All of the above

So you wouldn't have a need for bump. What you could do is add clean to the end of the install command cinst ruby -clean so it cleans up the old.

[ferventcoder]

And yes, right now when there are multiple active versions, PPAs break down a bit on keeping these separate if you try to treat them as the package. What we are looking to do here is create some meta packages that are dependent on a range of versions of a package so you can install them. What it doesn't handle very well right now is the upgrade scenario and why I haven't moved forward with it. It works right now just like it is, it's just not as easy for someone to see how they would get 1.8.7 and 1.9.2 of ruby and keep them updated independently. They have to use choco update ruby -version 1.8.7.### to go up and stay on 1.8.7.

These are special edge cases that don't always fit nicely into the versioning concept since they are maintained over time instead of deprecated for the newer versions. Nothing wrong with it, it just complicates things a bit, that's all.

[ferventcoder]

This is also where the evolution of the chocolateyInstall.ps1 will come in handy (where we break some areas into known functions chocolatey can call).

[rismoney]

I do like the cinst ruby -clean - That makes sense to me. The old versions can be determined using the -version all functionality I just wrote as a PR a few minutes ago against the current.

Now enter cup notepadplusplus. When you cinst it, you get the latest. perfect!
If a new version comes out, and you cup it, you get 2 folders in lib but only 1 version is installed. A new version comes out again, and you cup it 3 folders. In actually you only have 1 version of notepadplusplus.

In this use case- you want the cup process to automatically delete the lib folder for the version 1 rev behind. An upgrade is just that, a replacement of the version you specify (or replace latest if unspecified). Its not a side by side install, and i think chocolatey doesn't do much different for a cup.

I think in the case of ruby, most users are not going to cup ruby, and instead cinst the version they want.

[rismoney]

Maybe cup should delete all versions. I think that's what yum update might do.

Otherwise cinst...

[ferventcoder]

I think that's where the clean command comes in. Choco has no way of
knowing what us side by side and what is not. However a user pins packages
they want to keep and then later runs clean, it only cleans older pkgs that
are not pinned. Punning also excludes a pkg fron upgrade during cup all.

On Wednesday, March 27, 2013, Rich Siegel wrote:

Maybe cup should delete all versions. I think that's what yum update might
do.

Otherwise cinst...

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

---

Rob
"Be passionate in all you do"

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

[rismoney]

i understand what you are saying about pinning, which I am down with. Do you think this should be a 'feature' of the config file? say a pinned packages element. Do we leave this up to the user to populateor leave it to package authors to tamper with chocolatey.config? (ugh-security)...

I have a production request to nail down the default behavior for cup. Its getting to the point, where package authors are building crazy logic into chocolateyinstall.ps1... chocolateylib is gettting messy.

If there are areas where we are giving the users a choice, like in your uninstall example, we also need command line switches to force behaviors for non-interaction.

[ferventcoder]

Pinning is always from a user, never from a package author.

---

Rob
"Be passionate in all you do"

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

On Sun, Mar 31, 2013 at 8:31 PM, Rich Siegel notifications@github.comwrote:

i understand what you are saying about pinning, which I am down with. Do
you think this should be a 'feature' of the config file? say a pinned
packages element. Do we leave this up to the user to populateor leave it to
package authors to tamper with chocolatey.config? (ugh-security)...

I have a production request to nail down the default behavior for cup. Its
getting to the point, where package authors are building crazy logic into
chocolateyinstall.ps1... chocolateylib is gettting messy.

If there are areas where we are giving the users a choice, like in your
uninstall example, we also need command line switches to force behaviors
for non-interaction.

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

[TomOne]

I think it’s not a good design to keep the older versions of packages, because it has several drawbacks:

• It wastes disk space, especially when there are big files inside the package folder in C:\Chocolatey\lib.
• The cuninst command would only uninstall the latest installed version of a package and leaving behind the other versions. That is not how an uninstall command is intended for other package managers.
• Causes issues with applications that store data inside the C:\Chocolatey\lib\somepackage.version folder. If a package gets updated, these data rests in the older version folder. Of course this data can be manually moved to the new version folder or moved with some lines in the ps1-file, but this makes things only more complicated than they should be.
• Leaving multiple versions of a package on the machine would make sense only in one case: If the newer version is not backwards compatible with the older version. The package managers for Linux solve this with different packages for the older and newer version, for example one for Python 2.x and one for Python 3.x, the same for Ruby 1.9.x and Ruby 2.x. I think that’s a far better solution.
• If an user keeps two versions of one package on his machine, let’s say Ruby 1.9.3 and Ruby 2.0, the older version doesn’t get updated automatically, because it only updates to the newest version starting from 2.0. If for example a bugfix for Ruby 1.9.3 gets released, with the current chocolatey package design the user doesn’t get an update for it unless he does it manually. That’s bad. With the design of the Linux package managers this issue does not appear.
• The paths to files inside a chocolatey package folder (C:\Chocolatey\lib\somepackage.someversion\tools\…) is complicated. Even if the executables from a package get covered by the PATH variable it can be sometimes necessary to manually input a path into the commandline or open it in a file manager. Then the user has to remember which version of the package he wants. Also when using scripts it is not good when the package folder always changes. Better would be the path C:\Chocolatey\lib\somepackage for the related files, without the version.
• Of course there can be a small number of folks which absolutely wants to keep multiple versions of a package at the same time, even if they are backwards compatible. But remember, Chocolatey is a package manager, not a backup solution. If one absolutely wants to keep several versions, he should consider making manual backups of the affected packages. But for most people keeping all the versions of packages is totally unnecessary and has all the disadvantages I specified before. Package managers for Linux handle it like this. I never heard that somebody complained about that. :)

Let’s get to the advantages of dropping the current design of keeping multiple package versions. Some of them can be derived from the previous text:

• Uses less disk space.
• The cuninst command would work like expected and how it already works in other package managers.
• No loss of user data when a package gets updated.
• Would make binroot obsolete, because the paths to package folders won’t differ on an update.
• Less complexity and therefore better conformity with the KISS principle.

Now I hope I could convince you that this design is better. :)

[rismoney]

any interest in a helper like this: (taken from one of our sysadmins who used it in a recent package) I horrendously adapted it for understandiing

Function ChocoCleanUp {
  #Clean up previous installs out of lib folder if they exist
  $chocolateyLib = 'c:\chocolately\lib'
  $packagever = "1.2.3"

  Write-Host "* Cleaning up legacy lib folders in c:\chocolatey" -foreground green -background black
  Remove-Item $chocolateyLib\$packageName* -Force -Recurse -Exclude $chocolateyLib\$packageName.$packageVer -ErrorAction SilentlyContinue
  Write-Host "* Done" -foreground green -background black
}

[rismoney]

so are we needing a -pin switch, and what does it do? Touch a pinned.txt 0 byte file in it's lib?
and if it's not there, we do something like the helper I put above?

Trying to understand how we should be creating future packages...

[ferventcoder]

The pin keeps a package from being upgraded. Like you want to pin a particular version.

[rismoney]

do you pin during install, or do you pin as a separate op, or both should be supported.
ie

Method 1.
choco install sysinternals -pin

Method2.
choco install sysinternals
choco pin sysinternals

[ferventcoder]

Method 2 only

[rismoney]

We do not remove the previous version at all when a new version comes in by design. You can install two versions of ruby

this whole topic confuses me, and a lot of ideas.
Q:

1. Should we have the install and uninstall call a function ChocoCleanUp if a pin is not set?
2. Should we push this responsibility to the package author? So a ruby package author wouldnt call chococleanup, but a notepadplusplus would? I don't like this idea as it adds unnecessary clutter to authorship. Right now this is what our sysdmins have to do, due to lack of options. Or should they have the ability as "just another option"
3. we need a choco pin shim (lol, it just sounds funny)
4. we need a choco pin param in config mgmt providers - (Kinda why I suggested Method 1 for ease)

[FichteFoll]

After running cup a few times some time ago I currently have these folders in my C:\Chocolatey\lib folder:

Atom.0.101.0
Atom.0.96.1.0
flashplayeractivex.13.0.0.182
flashplayeractivex.13.0.0.206
flashplayeractivex.14.0.0.125
flashplayerplugin.13.0.0.182
flashplayerplugin.13.0.0.206
flashplayerplugin.14.0.0.125

What I expected: flashplayer derivatives should've been removed, Atom should've copied old user data and then also be removed. If I wanted to have different/multiple versions installed, I would've used cinst.
Now I face the problem that I don't know which packages are safe to remove or which require additional steps, such as copying user data.

So, should package authors take care of that? Most packages don't even have an uninstall script...

Edit: Just saw #400 and #6. Really sad.

[ferventcoder]

No, this is something chocolatey is going to do by v1.

On Thu, Jun 26, 2014 at 9:01 PM, FichteFoll notifications@github.com
wrote:

After running cup a few times some time ago I currently have these
folders in my C:\Chocolatey\lib folder:

Atom.0.101.0
Atom.0.96.1.0
flashplayeractivex.13.0.0.182
flashplayeractivex.13.0.0.206
flashplayeractivex.14.0.0.125
flashplayerplugin.13.0.0.182
flashplayerplugin.13.0.0.206
flashplayerplugin.14.0.0.125

What I expected: flashplayer derivatives should've been removed, Atom
should've copied old user data and then also be removed.
Should package authors take care of that? Most package don't even have an
uninstall script...

—
Reply to this email directly or view it on GitHub
#259 (comment)
.

Rob
"Be passionate in all you do"

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

[TomOne]

What I expected: flashplayer derivatives should've been removed, Atom should've copied old user data and then also be removed.

I have another less complicated idea. Why not simply leave off the package version from the package folder name? That would make things a lot easier to handle. Then no user data copying would be needed. I already explained some other benefits that this approach in my previous comment: #259 (comment)

Chocolatey has a really weird design in this area that I’ve never seen at any other package manager. Do you really think that it is so common that one wants to keep all package versions ever installed? In most cases that isn’t even possible. For example, most of the software that comes with an installer will overwrite the previous version by default. Therefore having a flashplayerplugin.13.0 and a flashplayerplugin14.0 folder is not only confusing, but also semantically incorrect, because in that case only Flash Player 14.0 would be installed on the system.

I want to ask you how often one would really need to have multiple versions of the same package installed at the same time. The only case where that would be 100 % possible would be portable packages. But even then it would not be easy to implement a good way to handle this. I’ve worked with Linux for several years now, where package managers are an essential part of the system and I never had the need to install multiple versions of the same package at the same time. I also never heard of one that would need that and nobody who complained about the fact that upgrading a package overwrites the previous version.

@ferventcoder, please consider a better design for the rewrite of Chocolatey as I already described in #259 (comment)

[ferventcoder]

@TomOne what's your suggestion for jre where you need both 32bit and 64bit at the same time?

Separate packages right?

[TomOne]

Yes, that’s the most straightforward solution, isn’t it?

[nemchik]

By comparison if you look at apt-get (which chocolatey seems to be compared to often) there are separate architecture packages any time you have a program that can run in parallel with it's alternate architecture counterpart. If a program is multi-arch you'd only need one package, but otherwise you get two, and if you need both you install both.

[FichteFoll]

How about a meta package that installs all arch versions available for your arch? Like, x86 for a 32bit OS and both x86 and x64 for a 64bit OS? This of course requires two separate packages for the archs too, so you can install them manually if desired.

On another note, there are cases where you'd very rarely want both versions installed at the same time and defaulting to installing both could be unnecessary there.

[nemchik]

I kinda think that should be up to the package maintainer.

If you're going to post a package you should take the architecture
specifics into consideration.
Some apps may not allow you to have both the 64 and 32 bit versions
installed and one might overwrite the other (even though windows tries to
separate program files x86).

In the case of Java I agree a meta package would be handy.
On Jul 12, 2014 2:48 PM, "FichteFoll" notifications@github.com wrote:

How about a meta package that installs all arch versions available for
your arch? Like, x86 for a 32bit OS and both x86 and x64 for a 64bit OS?
This of course requires two separate packages for the archs too, so you can
install them manually if desired.

—
Reply to this email directly or view it on GitHub
#259 (comment)
.

[emberquill]

The way I see it, the vast majority of packages are not really meant to have multiple versions installed simultaneously. Most things you'd want to install in parallel (like Python 2 / Python 3 and Java 7 / Java 8) are already in separate packages, anyway. For those that aren't, maybe cinst should be used to install a new version without overwriting the old, while cup would by default just update and replace old packages. When/if version pinning ( see #5 ) is implemented, it would help users keep packages they want to keep while updating the rest without breaking anything.

The current behavior breaks file assocations (unless you remember to associate files with the shim instead of the application itself, but then all files get the generic Chocolatey icon no matter what program they're assocated with), Explorer integration, and pretty much every other level of integration (other than the shims) with every update. Atom, for example, has a context menu option to Edit with Atom, but I never know what version of Atom will open when I use it. Usually it uses the oldest version available.

[ferventcoder]

This is a non-starter as the c# version does not display the behavior of multiple versions installed. Or in other words, this is already fixed for choco.exe. ;)

[ferventcoder]

If you watch the video here, I circle the ability to add the old behavior - https://www.youtube.com/watch?v=sm_U53sxt2c

[FichteFoll]

👍

[ferenczy]

Neither choco clean or choco install <package> -clean works in a version 0.9.8.28, Chocolatey doesn't know such commands.

choco update <package> does the same as choco install <package>. Wouldn't be better to remove the update command completely until it will really update packages instead of installing new ones? It's quite confusing. I would use choco install <package> -version x.y.z, if I needed more different versions of one package. I would never expect that update command will not update anything and instead it'll install another version. No package manager works like that.

How it looks with a new client currently? Is it still planned to release before the end of 2014?