[question] Conan centre package rereleases

[KingKiller100]

What is your question?

Conan version: v1.64.0
OS version: Windows 11

Hi,

I have several conan project that utilizes packages from my company's local Artifactory conan repository and conan center. We store our 1st party tools and products in our local artifactory and have started point to conan centre to retrieve the 3rd party libraries, build them locally then upload the recipe and package to our local artifactory. Over time, I've noticed that a few packages we have stored fail to be installed due to the recipe hashes not matching up. This is due to 3rd party dependencies relied on have been rereleased with a new recipe for a previously released version. For example, boost v1.81.0 had a release and caused issues for installs

We couldn't find any clear docs to cover what to do when the packages you rely on are rereleased on conan centre and conflict. To work around this, we append the recipe hash to the end of the package reference so avoid the conflict i.e boost/1.81.0@#9bd7ae86a881631b6cc76590621e470b. This helps but hit issues when a dependency of a 3rd party is rereleased as well, causing somewhat of a domino affect of declaring each problematic dependency and declaring an overriding requirement with the target recipe hash until all issues are gone

My questions are the follow:

• What are the reasons for allowing libraries to rerelease recipes an previously released version instead of forcing them to make new unique releases?
• What are the ways we as users are meant to get around the issues I have detailed here? For example, is appending the recipe hash the correct solution, or could copying the built recipe from conan centre to the company's artifactory with a unique user/channel be a better one?

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @KingKiller100

Thanks for your question.

Quick question, have you read https://docs.conan.io/2/devops/using_conancenter.html? This would be updated advice on how to use ConanCenter packages in production environments.

[memsharded]

Regarding your questions:

What are the reasons for allowing libraries to rerelease recipes an previously released version instead of forcing them to make new unique releases?

Because often it is necessary to do changes to recipes, that still package exactly the same source code, for example the boost - 1.81.0 source code. When the recipe changes to accomodate some new compiler, architecture, or to solve a bug, it gets a new revision, yet the underlying packaged source code is boost/1.81.0. Conan cannot invent a new version different from the boost original version, that would be super confusing, so it generates a recipe revision instead.

What are the ways we as users are meant to get around the issues I have detailed here? For example, is appending the recipe hash the correct solution, or could copying the built recipe from conan centre to the company's artifactory with a unique user/channel be a better one?

The advice in https://docs.conan.io/2/devops/using_conancenter.html for your case:

• Do not use a different user/channel for ConanCenter
• Build your own binaries from source, from conan-center-index repo (in Conan 2 the new "local-recipes-index" feature can help with this: https://blog.conan.io/2024/04/23/Introducing-local-recipes-index-remote.html)

[KingKiller100]

Hi @memsharded, thanks for the swift reply. It is very much appreciated.

No, I have not seen those links before. Thank you for adding them here so I can reach them easily. I'll read over them and use the information to help my issue.

I noticed these links and your response mentions how Conan 2 is expected to work for production envs. Would the information in your response and these links extend to Conan 1.x series too (sadly not ready to upgrade to 2.0 yet)?

[memsharded]

I noticed these links and your response mentions how Conan 2 is expected to work for production envs. Would the information in your response and these links extend to Conan 1.x series too (sadly not ready to upgrade to 2.0 yet)?

Yes, most of the information in that docs is equally valid for Conan 1.X with a couple of notes:

• Creating and using lockfiles in Conan 1.X is far more complex than in Conan 2, where lockfiles have been greatly simplified and improved
• So the recommendation to create your own binaries from conan-center-index repo (or a fork) is probably even more recommended in Conan 1.X
• The local-recipes-index feature doesn't exist in Conan 1.X, but it is possible to achieve very similar results with some simple scripts.

[AshleighAdams]

@memsharded I think this is systemic of packaging not being contained with official sources like other ecosystems do, I personally believe Conan should take note from Debian, where rereleases use ~dsfg.* as post releases/repacks, and I don't think anyone finds it too confusing

[KingKiller100]

@memsharded I think @AshleighAdams has a very good point to consider. That would be a safer alternative to allow for developer teams to create new packages that patches issues but still live as a version of that release. With the boost example, we would still have the original boost/1.81.0 but when the rerelease is needed they would create a boost/1.81.0+1 as a package that is a v1.81.0 release but doesn't cause the conflict recipe. Means no need for companies to create mirror repos for ConanCenter

[memsharded]

With the boost example, we would still have the original boost/1.81.0 but when the rerelease is needed they would create a boost/1.81.0+1 as a package that is a v1.81.0 release but doesn't cause the conflict recipe

I am not sure how this is different from boost/1.81.0#revision1 and boost/1.81.0#revision2. Actually, having explicit versions as boost/1.81.0+1 causes way more conflicts than revisions that are implicit.

[KingKiller100]

Hi @memsharded , sorry for the late reply.

The general idea is the same. However, it would need the packages on Conancenter to either append the recipe revision to the dependencies or build off a lock file to ensure the intended recipe and version of each dependency package is found correctly.

At the moment, the recipes in the conancenter packages do neither. Take boost's recipe on conancenter as an example. These are transitive dependencies that do not enforce a recipe revision so rereleases of these deps will be an issue

[KingKiller100]

Actually, having explicit versions as boost/1.81.0+1 causes way more conflicts than revisions that are implicit.

Interesting... how so?