cChoco doesn't support Chocolatey's -m (multiple versions) parameter

[dragon788]

I need to install a few versions (previous and current) of a couple packages on a server and currently since it is the same package name and name is the primary key being used this fails when DSC goes to compile. It seems like maybe it should be possible to specify a list of versions in the Version: key and if a list or more than 1 element is detected then automatically pass the -m to chocolatey.

[dragon788]

Example packages that would require this option:
cinst microsoft-build-tools -m # This is actually v14 aka VS 2015 installer
cinst microsoft-build-tools -m -version 12.0.21005.20140416 # This is the v12 aka VS 2013 installer

[ferventcoder]

Does this not work when you pass chocoParams?

[dragon788]

I'll test this. I believe the issue I was having was that it keys off the "Name" aka package name as needing to be unique, so just supplying different parameters to each instance still rolled up to one overall package name that it didn't like.

[dragon788]

This is still an issue.

The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: A conflict was detected between resources '[cChocoPackageInstaller]installMSBuildTools2013 (::47::9::cChocoPackageInstaller)' and '[cChocoPackageInstaller]installMSBuildTools2015u3 (::55::9::cChocoPackageInstaller)' in node 'BuildAgent'. Resources have identical key properties but there are differences in the following non-key properties: 'Version'. Values '12.0.21005.20140416' don't match values '14.0.25420.1'. Please update these property values so that they are identical in both cases.

[ferventcoder]

Thinking out loud - I wonder if the other config mgmt tools allow for this. My guess is they do not do so well in this department either.

[elovelan]

This is clearly the wrong place for this discussion, but I'm not sure where it belongs, Google groups?

I think it may be wise to discourage use of the AllowMultipleVersions parameter for packages that are specifically able to be installed SxS. Many packages that can be installed SxS are already using different packages for each version (Visual Studio & vcredist and python for instance). Maybe this is as simple as enhancing https://github.com/chocolatey/choco/wiki/CreatePackages#what-version-of-the-software-should-i-package ?

This also seems to be the technique used by other packaging systems, with the default depending on the latest or most used. e.g. from Ubuntu:

• Ruby 1.9.3, Ruby2.0, Ruby2.3, Ruby
• Python3, Python2.7, Python

I've been thinking about this quite a bit recently.

Some examples of packages that can be sensibly installed side-by-side but currently require AllowMultipleVersions:

• Ruby
• microsoft-build-tools
• sqlserver-odbcdriver

Here are some of the issues:

• No automated upgrade path for point releases. e.g. if I have Ruby 1.9 and Ruby 2.4 installed, I can only upgrade Ruby 2.4, even if there's an update to 1.9
• Configuration management systems (at least Puppet and DSC) don't allow for multiple versions to be installed because they key on package name
• Future installs don't know that the previous one was installed with AllowMultipleVersions
• Inability to pin to a major or major.minor version
• Difficult to maintain packages for older versions if fixes are released (git branching could work, but many chocolatey packages are maintained in repos with multiple packages)
• Can dependencies depend on a specific version? Does this work right?

[ferventcoder]

Configuration management systems (at least Puppet and DSC) don't allow for multiple versions to be installed because they key on package name

This is a big reason here.

Future installs don't know that the previous one was installed with AllowMultipleVersions

This sounds like a possible bug? I mean they know (or at least have the info).

Can dependencies depend on a specific version? Does this work right?

Yes and yes.

[jberezanski]

One package which would benefit from this is dotnetcore-sdk. The way Microsoft implemented the SDK is that each three-part SDK version gets installed side by side with all other versions, e.g.:

C:\Users\Admin>dotnet --list-sdks
1.1.11 [C:\Program Files\dotnet\sdk]
1.1.12 [C:\Program Files\dotnet\sdk]
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.403 [C:\Program Files\dotnet\sdk]
2.1.504 [C:\Program Files\dotnet\sdk]
2.2.104 [C:\Program Files\dotnet\sdk]

It would be cumbersome to define a new package id for each A.B.C version of the SDK.

[pauby]

I'm unsure of how to proceed with this one as I can't see how it can be done in DSC when the Name properties are the same.

We dont encourage the use of SxS installs either so I'm inclined to close this with Won't Fix. However, I'll leave it open for a while yet to gather feedback (and I do appreciate this is a very old issue).

[jberezanski]

The cChocoPackageInstaller resource schema defines Name (i.e. package id) as the only key property, so that resource cannot support side-by-side versions.

However, a second resource could have this schema:

[ClassVersion("1.0.1"), FriendlyName("cChocoPackageSxSInstaller")] 
class cChocoPackageSxSInstall : OMI_BaseResource
{
  [Key] string Name;
  [Key] string Version;
  [Write,ValueMap{"Present", "Absent"},Values{"Present", "Absent"}] String Ensure;
(...)

in other words, use the tuple (id, version) as the DSC resource key (composite). The version specification would be mandatory (due to being part of the resource key) and the resource would automatically pass --side-by-side to choco.exe.

[jberezanski]

Personally, however, I no longer have a practical need to perform sxs installations, because last year I redesigned the .NET SDK packages family I mentioned in my earlier post and, at present, each .NET SDK "feature band" (the "smallest unit" devs need to install side by side with others) has its own package id.

And that is, I believe, the proper way to fix this issue - work with package maintainers and encourage them to provide separate ids for software versions which can and usually are installed independently (such as different PostgreSQL major releases).

[pauby]

And that is, I believe, the proper way to fix this issue - work with package maintainers and encourage them to provide separate ids for software versions which can and usually are installed independently (such as different PostgreSQL major releases).

Completely agree with this statement. SxS installations can be problematic, is only used by a handful of orgs (based on nothing more than comments I see in Chocolatey and here) and is difficult to troubleshoot. If we provide the functionality here, then we would have to support that.

[jberezanski]

However, having written the above, I thought about it some more and came up with a legitimate SxS scenario. This involves a certain kind of software, which usually updates in-place (newer versions overwrite the existing installation), but can also have multiple versions installed side-by-side if the user desires so.

The example would again be the .NET Runtime, where by default newer major.minor.patch releases replace the existing major.minor.older-patch installation (e.g. 5.0.7 replaces 5.0.6, but does not affect 3.1.*), but this behavior can be suppressed by a switch and one can have several major.minor.? versions installed at once (e.g. 5.0.4, 5.0.6, 5.0.7). The usage scenario here is on developer workstations and build servers, when companies wish to control the exact version of the .NET Runtime their applications are compiled against and bundled with (in self-contained deployment mode, when the runtime binaries are included in the compiled application package). Therefore, in a build server DSC config one might want to install multiple versions of the dotnet-5.0-runtime package.

(Not my scenario at the moment, because right now in my company we do not exercise such precise control over the runtime versions our software is compiled against - we always use the latest patch - but it could possibly change in the future if regulatory requirements force us to have fully repeatable builds, for example.)

[pauby]

As Chocolatey CLI will remove support for side-by-side installations in version 2.0.0, I'm going to go ahead and close this.