Add a parameter --lts to the choco install command

[lebarsfa]

Checklist

• I have verified this is the correct repository for opening this issue.
• I have verified no other issues exist related to my request.

Is Your Feature Request Related To A Problem? Please describe.

No response

Describe The Solution. Why is it needed?

I think what I will describe is more or less the rationale behind the concept of LTS (Long Term Support) for Ubuntu.

I imagine it could be good if a user could do e.g.

choco install --lts libopencv-dev qt6-base-dev codac qtcreator

In 2024, it would be resolved automatically to

choco install --tag LTS2024 libopencv-dev qt6-base-dev codac qtcreator

but in 2026, it would resolve to

choco install --tag LTS2026 libopencv-dev qt6-base-dev codac qtcreator

It would be the Chocolatey Community Repository maintainers that would decide every 2 year to change to which "year/distribution" resolves --lts parameter default, like Ubuntu maintainers decide to publish a new LTS version of Ubuntu distribution every 2 years.

When a package maintainer tags a version of a package as LTS2024, it would mean that it made its best so that this specific version is compatible with other packages with the same tag, without much breaking changes w.r.t. any previous versions of this package that are also tagged LTS2024 (the versions available for Ubuntu 24.04 should be a good hint about compatibility between different packages). If unsure, it would be probably better to not tag the version. Thus, a user that runs

choco install --tag LTS2024 libopencv-dev

would get the latest version of the package that has a tag LTS2024. If no version is tagged, possibly return an error (--force could install the latest instead?)...

Additional Context

The idea is since Windows and Ubuntu are typically available in CI tools like Github Actions hosted runners, it could be handy on Windows to get easily a distribution of tools with versions very similar to the one we get when installing corresponding tools using apt package manager with default repositories on latest (or a specific) Ubuntu LTS version.

At the moment, it is up to Github Actions hosted runners maintainers and users to try manually to find/guess which versions of the different packages should work the best together, e.g. by checking manually what are their common dependencies if any and other problems, without knowing what was the initial intention of the package maintainer.

The packages I have in mind are typically developer packages such as qt, opencv, or other libraries and IDEs that have strict dependencies especially on the compiler (e.g. gcc/mingw) version used, but this is also true for any application that we would like to be the same on Windows and latest Ubuntu LTS.

In terms of implementation, I would say maybe the --pre parameter could have some common points...
The concept of tag already exists, I don't know if it should be better to create another specific concept or version suffix named ltsXXXX since it is quite linked to specific packages version... Maybe the --tag parameter could also be used as other easy way to install somehow linked packages and multiple tags could be specified...
Also, I don't know if the tag naming format LTS2024 I propose is the best, it could be LTS24.04 to match better Ubuntu naming conventions and date availability, or e.g. LTS24H1 but interested package maintainers should all be aware of the correct tag format so that it works. It would be probably up to the Chocolatey Community Repository maintainers to have authority on that.
In the same idea, other special tags could be interesting, e.g. DebianBookworm, etc.

Related Issues

No response

[lebarsfa]

Implementations of choco upgrade --lts all (could act as if a pin has been made on all packages except those with the correct tag, for which a kind of "weak" pin allowing to consider different versions with the same tag would be applied…?)
, choco outdated --lts all may also limit the occurence of #3496 while helping to keep security and bug fixes.

[pauby]

Thanks for raising this @lebarsfa. I do appreciate the effort and content you put on the issue.

There is a lot here, so I'm going to take each part separately.

It would be the Chocolatey Community Repository maintainers that would decide every 2 year to change to which "year/distribution" resolves --lts parameter default, like Ubuntu maintainers decide to publish a new LTS version of Ubuntu distribution every 2 years.

There is no collective "Chocolatey Community Repository maintainers" that would decide on that. The Chocolatey Team is what, I think, is being referred to here.

How to we deal with packages that don't fit into any cycle we determine? For example, we agree 2 years and the package lifecycle is 18 months, or 12 months, or 3 years? We would need to have different standard and tagging for different lifecycle. Not everything in Windows works to the same standards (or any).

specific version is compatible with other packages with the same tag, without much breaking changes w.r.t. any previous versions of this package that are also tagged LTS2024 (the versions available for Ubuntu 24.04 should be a good hint about compatibility between different packages)

Maintainers are generally speaking not the vendors of software, so they wouldn't know this information, and it would be a burden they may not want to accept and not one we would want to enforce.

When a package maintainer tags a version of a package as LTS2024

Packages are tagged, not package versions. If a maintainer adds LTS2024 to any package version, the entire package is tagged this way. This is intended as packages are for a specific purpose that tags lend themselves to, and that purpose would not change between versions. For example, Notepad++ may have the tag editor and that won't change from version 1.0.0 to 10.0.0. It would still be an editor.

So if you have three versions, 1.0.0, 2.0.0 and 3.0.0 and you tag 2.0.0 as lts2024 and you then release 3.0.0, it will also be tagged with lts2024 even though it may not be intended as the LTS version.

At the moment, it is up to Github Actions hosted runners maintainers and users to try manually to find/guess which versions of the different packages should work the best together, e.g. by checking manually what are their common dependencies if any and other problems, without knowing what was the initial intention of the package maintainer.

I know this is a problem on Linux where packages widely use different dependencies which can be incompatible with each other and other applications. It's one of the reasons for Flatpak and Snap being so popular.

The Windows ecosystem isn't so reliant on this. I acknowledge that it happens, but not to the same extent as we have on other operating systems. So the issue of dependency hell isn't as widespread with Windows software as it is on other operating systems. People spending a lot of time making sure the software is compatible is, by extension, not as widespread on Windows.

For a GitHub Actions runner, you'll likely install specific versions of packages rather than just using any LTS version.

The packages I have in mind are typically developer packages such as qt, opencv, or other libraries and IDEs that have strict dependencies especially on the compiler (e.g. gcc/mingw) version used, but this is also true for any application that we would like to be the same on Windows and latest Ubuntu LTS.

I would agree here that this scenario would be able to make use of such tagging. But it isn't a widespread use case that implementing an LTS system would be worthwhile. To achieve compatibility, you would rely on specific versions of packages as you know they are compatible. Chocolatey CLI allows for that.

Maintainers could also provide LTS packages. So you would have package and package-lts and people could just install the ...-lts version of the package.

In the same idea, other special tags could be interesting, e.g. DebianBookworm, etc

Again, like the issue of dependency hell, this isn't really an issue on Windows. By and large, Windows XP, 7, 8 and 10 software will all work on Windows 11. That is part of the goal of Windows - backwards compatibility. So the concept of bookworm, testing, unstable don't apply in the Windows world where they do to Debian.

I understand the concept of what you are proposing, but I don't feel that imposing what Linux does to Windows is appropriate here for the reasons mentioned above. I don't believe it would work. The re-engineering of Chocolatey CLI to support this, along with the work required to communicate and work with maintainers to implement a tagging standard for this, would not provide enough value to the community or customers as a whole. I believe this is a niche area that can be solved using versioning for some (probably not all) circumstances.

[lebarsfa]

Thank you for your detailed answer.

I understand my misunderstanding about how tags work.

In that case, making package-lts in addition to package could be also an idea, indeed there is e.g. libreoffice-fresh and libreoffice-still, but it should be more package-lts2022, package-lts2024, etc. that should be done so that users could blindly use choco upgrade to get theoretically non-breaking updates that follow the same lifecycle of their Ubuntu LTS versions counter-parts.

This would multiply the number of packages and they would be probably left unmaintained after the LTS period expires, but maybe it is not much a problem if in reality few packages follow that (that's true that in practice, users that have strong compatibility constraints often just install and pin a specific version, at the cost of missing potential non-breaking updates if they do not check them manually).

So maybe it could be a naming convention (like there is a naming convention for package.install, package.portable) that could be advised, so let's say that it is here that we gave first advice!

I realize also this turns out to be related to the problem of side-by-side installations, where the cleanest workaround is probably also to maintain different package IDs of the "same" package.

[pauby]

but it should be more package-lts2022, package-lts2024

That is a matter for maintainers. We don't enforce package naming standard like this.

that follow the same lifecycle of their Ubuntu LTS versions counter-parts.

The vast majority of people do not care about this (with all respect). They are Windows users. What happens in Ubuntu is opaque to them.

So maybe it could be a naming convention (like there is a naming convention for package.install, package.portable) that could be advised, so let's say that it is here that we gave first advice!

The Chocolatey Community Repository moderators would have to enforce the use of LTS versions both for packages not named that way and for packages that are. That is not a burden we would place upon them.

[lebarsfa]

I just meant without enforcement, if someone wants to create a package that falls more or less in the cases I describe and wonder how he should name the package(s), maybe he would find this issue and take it as inspiration to make a name choice if there are no other specific constrains.

One of my initial guess was that a significant use of Chocolatey packages is through the virtual machines of the Continuous Integration tools that try to provide similar environments whatever the OS, but maybe it is not much the case, so there is probably no need to worry much about what I described.

[pauby]

I just meant without enforcement, if someone wants to create a package that falls more or less in the cases I describe and wonder how he should name the package(s), maybe he would find this issue and take it as inspiration to make a name choice if there are no other specific constrains.

If somebody wants to name their package in this way, there is no issue. If a group of maintainers got together and agreed to do it, that would be awesome. I'd encourage that.

The enforcement part of my reply came from the word should that you used. I took that to mean must or 'not voluntarily' and therefore would have to be 'enforced'.

I'm unsure there is much else we can, or should, do regarding Chocolatey CLI. So I'll go ahead and close this issue. We can always reopen it again if necessary.