Problems updating packages with existing dependencies pushed by previous versions of Chocolatey (probably due to SemVer v2 enforcement since choco v2)

[lebarsfa]

Checklist

• [X] I confirm there are no unresolved issues reported on the Chocolatey Status page.
• [X] I have verified this is the correct repository for opening this issue.
• [X] I have verified no other issues exist related to my problem.
• [X] I have verified this is not an issue for a specific package.
• [X] I have verified this issue is not security related.
• [X] I confirm I am using official, and not unofficial, or modified, Chocolatey products.

What You Are Seeing?

https://community.chocolatey.org/packages/libopencv-dev/4.5.4.20240807#versionhistory is saying "Waiting on dependencies" forever. The changes in the package are only links and corresponding checksums in chocolateyInstall.ps1. This seems linked to a silent change made by choco pack that removes leading 0 in its mingw dependency version numbers. A possible workaround seems to pack with an older version of choco, e.g. v1.4.0.

What is Expected?

Ideally, providing minor fixes to existing packages should be as easy as possible.

How Did You Get This To Happen?

EDIT 2024-08-14: some of the mentioned links may have been updated in the meantime.

I was trying to do:

choco push libopencv-dev.4.5.4.20240807.nupkg

which returned success, I received a confirmation e-mail but the status on https://community.chocolatey.org/packages/libopencv-dev/4.5.4.20240807#versionhistory was saying "Waiting on dependencies" and did not seem to change while other packages I submitted near the same time seemed to follow the usual procedure.

So, I looked below on the page and saw "mingw (= 11.2.0.7112021)" in the dependencies and clicked on the underlying link (https://community.chocolatey.org/packages/mingw/11.2.0.7112021) which said 404 error. Indeed, the version I needed was 11.2.0.07112021 (with leading 0), as still correctly listed on https://community.chocolatey.org/packages/libopencv-dev/4.5.4.20240203#dependencies , which is the previous version of the package for which I want to provide a fix.

I checked my libopencv-dev.nuspec and it was correctly showing 11.2.0.07112021 but after choco pack and extraction of the resulting .nupkg, I see that choco pack changes 11.2.0.07112021 to 11.2.0.7112021 in the .nuspec, hence the problems.

Then, I realized that it was probably since Chocolatey v2 that versions are corrected and the last time I used choco pack for a package with dependency "mingw (= 11.2.0.07112021)" was probably with Chocolatey v1.4.0. So, I prepared a virtual machine, installed choco, and then downgraded it:

choco upgrade -y chocolatey --version=1.4.0 --allow-downgrade

Then, I packed https://community.chocolatey.org/packages/libopencv-dev/4.10.0 (which also had the same problems) with that version of choco and pushed from my main computer which has choco v2.2.2 and I do not see problems up to now.

Is there a better solution for this type of problem?

System Details

• Operating System: Windows 10
• Windows PowerShell version: default
• Chocolatey CLI Version: 2.3.0, 2.2.2
• Chocolatey Licensed Extension version:
• Chocolatey License type:
• Terminal/Emulator: CMD

Installed Packages

N/A

Output Log

N/A

Additional Context

I took note of these issues when searching for a solution:

• https://github.com/chocolatey/choco/issues/3415 : mentions "In 2.x versions of Chocolatey, if you provide a version number with leading zeroes in your package, it will be normalized to remove them".
• https://github.com/chocolatey/choco/issues/3356 : mentions "version normalization behavior, and was a breaking change in Chocolatey CLI v2.0.0: https://docs.chocolatey.org/en-us/choco/features/version-number-normalization".
• https://github.com/chocolatey/choco/issues/3458 : mentions compatibility problems between packages created with choco v2.2.2 for choco v1.4.0 (but with the workaround I used I am in the inverse situation so I am probably not affected by this issue).
• https://github.com/chocolatey/choco/issues/3185

[pauby]

Chocolatey CLI 1.x is not supported for open-source users. The latest version is 2.3.0 so that should always be used going forward.

Can you take a dependency on a different version of minigw?

[lebarsfa]

Can you take a dependency on a different version of mingw?

The short answer would be yes and no!

The library OpenCV 4.5.4 do not build out of the box with more recent versions of MinGW. Therefore, I consider those versions of MinGW as not recommended for people that would need specifically OpenCV 4.5.4.

However, latest version of OpenCV do build correctly with latest MinGW available on Chocolatey and indeed, I submitted a package for that scenario: https://community.chocolatey.org/packages/libopencv-dev/4.10.0.20240808. That being said, to try to maximize compatibility, I made also some hopefully non-breaking fixes to be able to build and use OpenCV 4.5.4 with more compilers and they are available using package parameters and they are the purpose of the package I was trying to submit.

In reality, I am somehow trying to find a way to do some parts of what I suggest in https://github.com/chocolatey/choco/issues/3497. The scenario is that I have C++ code that should ideally work as close as possible whatever we are on Ubuntu 22.04 or Windows (I guess I am not the only one to want that?). On Ubuntu 22.04, gcc is 11.2.0, libopencv-dev is 4.5.4, qt6-base-dev is 6.2.4, so I would like to provide the same on Windows, with still the possibility to provide minor ideally non-breaking fixes, as sudo apt upgrade does on Ubuntu, with a standard support of several years. And in the same time, same idea for Ubuntu 24.04 with gcc 13.2.0, libopencv-dev 4.6.0, qt6-base-dev 6.4.2, all these equivalents are currently published/submitted also on Chocolatey.

Fortunately, in the end it looks like Chocolatey is close to be compatible with what I describe!

[pauby]

It sounds to me like the best solution would be for a minigw package to be published with a normalized version.

I can't see anything else for us to do here?

[lebarsfa]

Indeed, this is probably the cleanest way to solve that issue, since it is probably quite rare.

I will signal the problem to the maintainers of the mingw package, and whatever their answer, in the meantime I can still pack the package with Chocolatey v1.4.0 as I mentioned.

[github-actions[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue will be closed in 14 days if it continues to be inactive.

[github-actions[bot]]

Dear contributor,

As this issue seems to have been inactive for quite some time now, it has been automatically closed. If you feel this is a valid issue, please feel free to re-open the issue if / when a pull request has been added. Thank you for your contribution.