[Enhancement] Uninstall all versions of a package

[codearoo]

and also.. to provide parameters of the sub-commands. For example, I would expect this:
choco uninstall /? or cuninst /?
to show me special options just for the un-install process.

There it would make sense to have something like a -all option to remove ALL versions of an app, not just the last one.

example usage:
cuninst putty -all

because otherwise, you have to repeatedly issue 'cuninst putty' until all versions are finally gone.

[codearoo]

Maybe to avoid confusion with the "all" option which is for "all packages", the "-all" for "all versions" maybe should be called "-all-versions"

[codearoo]

Well actually, to be consistent with "-version xxx" option for like 'cinst myapp -version 1.123" maybe it should be something like this.. and also noticing the uninstallation of a specific version does not work:

cuninst myapp -version 1.123
cuninst myqpp -version *
cuninst myqpp -version all
cuninst myqpp -version-all

[codearoo]

I also wanted to post up a new feature to allow you to remove OLD VERSIONS of software. For example:

cuninst all -version-old
???
so that it only leaves the LATEST versions of the packages.

[codearoo]

I found another issue ticket mentioning that this works:
cuninst myapp -version 1.123

but it does not.. unless it meant that it SHOULD work.

Also laughed at the old name 'cunst' :)

I still think it's easier to remove most of those aliases and just get users used to using 'choco'

choco install
choco uninstall
choco /? then would work without the user typing: cinst /? and wondering why it's trying to install "/?" package.

[TomOne]

I also wanted to post up a new feature to allow you to remove OLD VERSIONS of software.

Like it. But if you ask me, it should be the default behavior of Chocolatey to remove the old version when a package gets updated. Every other package manager on Linux (apt-get, yum, opkg, pacman) does that.

Please forgive me if I am a bit direct here, but I think the current design of Chocolatey to keep older package versions is neither useful nor appropriate. Why don’t follow the design of well established package managers that have already millions of (mostly satisfied) users?

Maybe some people think here that it’s sometimes needed to keep for example older versions of the same Ruby package (for example 1.9 if their app is not compatible with 2.0). But it is the wrong approach, because doing so the idea of a package manager would be undermined. If you have for example two versions of exactly same package installed (let’s say Ruby versions 1.9 and 2.0), the Ruby 1.9.x branch would never be automatically updated, because 2.0 is already newer. If the 1.9.x branch would get an important security update, you would miss it with the current design of Chocolatey, because version 2.0 is newer than 1.9.x.

It is far better to keep different packages for each maintained branch, e.g. ruby1.9 and ruby2.0. The same applies to candidates like php5.3, php5.4, and php5.5. Note that also this approach is already used in the Linux package manager world. The benefits of this: an user can choose which branch he would like to install and then that version automatically gets its updates.

Or can you tell me what is the actual benefit to have these packages installed simultaneously?

• CCleaner 4.08.4428
• CCleaner 4.07.4369
• CCleaner 4.06.4324
• CCleaner 4.05.4250
• CCleaner 4.04.4197
• CCleaner 4.03.4151
• CCleaner 4.02.4115.20130609
• CCleaner 4.02.4115.20130601
• CCleaner 4.02.4115
• CCleaner 4.01.40933
• Java Runtime (JRE) 7.0.45
• Java Runtime (JRE) 7.0.40.20131007
• Java Runtime (JRE) 7.0.40
• Java Runtime (JRE) 7.0.25
• Java Runtime (JRE) 7.0.21
• Java Runtime (JRE) 7.0.17
• Java Runtime (JRE) 7.0.15
• Java Runtime (JRE) 7.0.11
• Java Runtime (JRE) 7.0.9
• Java Runtime (JRE) 7.0.5.1
• Java Runtime (JRE) 7.0.5
• Java Runtime (JRE) 6.0.31.1
• Jave Runtime (JRE) 6.0.30

Please also read my other statements why the design to keep older versions is bad idea: #259 (comment)

[codearoo]

are you sure Linux apt-get REMOVES old versions? I thought it only does
that when you run 'apt-get autoremove'

I think it's useful to have old versions locally so you can revert back to
them and not rely on the remote source being online. However I would be
fine with it removing by default when you install... and maybe adding an
option to not do that if the user does not want it.

cinst myapp -leave-old

or something like that.
I did not request it that way because I actually thought how it was working
now is in line with 'apt-get'.

[codearoo]

Regarding your multiple branch thing.. that is ALREADY the case, but maybe
not for all apps. Ruby however DOES DO THIS:

cinst ruby <-- latest stable release of ruby (hopefully) which is 2.0.xx
cinst ruby1.9 <-- only install latest (again hopefully) of 1.9 branch

Someone recently added that 1.9 package.

And in general I also agree that 'apt-get' is the syntax and form to strive
to since it advertises as being the 'apt-get for Windows' however doing
that now would mean breaking old habits so not sure how good that would be.
But moving forward borrowing those ideas probably would only help.

[ferventcoder]

This is a duplicate of #295. However that one has bad naming as compared to this one, so I will close it as a dupe of this.

[ferventcoder]

This is really a duplicate of #6 (just FYI).

[codearoo]

I see... only one thing... since Chocolatey had the goal in mind to JUST DO IT.. making it interactive would conflict with that. Or at least... if you do, then also add some general -y -quiet option to force it to not interact. Fail in certain cases or something.. just provide a way for automated scripts to do whatever the job is.

[TomOne]

are you sure Linux apt-get REMOVES old versions?

Yes, 100 % sure. 😄

I thought it only does that when you run 'apt-get autoremove

No, apt-get autoremove does something completely different: autoremove is used to remove packages that were automatically installed to satisfy dependencies for some package and that are no more needed.

I think it's useful to have old versions locally so you can revert back to them and not rely on the remote source being online.

Exactly that is not possible with Chocolatey at the moment, because it downloads files every time when you install a package, even if exactly the same files were already downloaded previously. So it’s not a “smart” download cache like apt-get has.

[ferventcoder]

Installs are silent and scriptable, that doesn't mean other actions should also be (by default). That might be where you pass a switch to make it so.

Note that the uninstall in choco at the moment is very naive, it doesn't do much without help.

And to touch on @TomOne 's suggestion - I have been giving that alot of thought and I think we will move that way. Choco is 100% semver compliant (AKA no real rules for less than v1), so wild changes are still okay while we are working out how it should be for the release.

[codearoo]

ALSO... sort of tied with this issue.. in that it eats up disk space a lot.. is this post I wrote about Nuget Cache:

https://groups.google.com/forum/#!searchin/chocolatey/nuget/chocolatey/pM0kIM6A3p8/U8fxJPiDsToJ

[ferventcoder]

I'm not a fan of that as much as you are not (the nuget cache)....

[TomOne]

I would prefer a cache management like apt-get has. To download again already downloaded files like Chocolatey does is a bit inefficient, don’t you think so?

[ferventcoder]

@TomOne I agree. One needs to have a hash in the package so you know that the local is the same as the MD5 hash so you wouldn't have to download it again. Perhaps search and open an issue on this?

[TomOne]

@ferventcoder yes, good idea. I’m going to do that.

[ferventcoder]

choco uninstall pkgname --all-versions