Conan-center-index: [service] Please start a discussion what guarantees for package stability (don't break randomly things) are possible to give

[a4z]

With the raise popularity of conan, and getting more and more contributions, I think it is time to to think about some stability guarantees for the recipes the conan-center-index provides.

As example, I refer to the latest change in the paho-mqtt-c pacakge
This package changed from being delivered as a static lib to build per default as a dynamic lib.
Also for older versions. Which break my builds for no good reason.

Beside the fact that the argumentation why this is the case is not convincing at all to me at all and I think it mirrors more the specific use case of 1 user, very likely that one who submitted the change, this is a breaking change that should not have happen.

And it puts me into a problem, namely, shall I for the recipes I use from the cci to my own repo.
This would mean it would be more cumbersome to contribute back changes and additions I do to the cci
I could imagine that this is a problem also other users have, but most of them will silently create their own index and the problem will never reach your attention .

As a begin I would suggest to create a rule that the default for packages has to be static libraries.
Second, it might not be enough to build all libraries that a change effects, but also those packages that depend on a library that consumes the updated/changed package. (This would, for example, have shown that paho-mqtt-cpp is not happy about the change that has happened in paho-mqtt-c on all configurations.

I understand that this is a huge undertake and causes costs.
But maybe it is more important to proved quality and stability over number of packages.

In any way, it would be nice to have a discussion about this and know the thoughts and directions the cci is having and going to take, since with more and more contributors to the cci, the situation could become easy chaotic.

[Croydon]

As a begin I would suggest to create a rule that the default for packages has to be static libraries.

it de-facto is, but maybe we could add a hook to automatically enforce this rule (with an allowlist for very, very special cases)

[a4z]

this is for sure a good begin, but there is more.

as mentioned, ensure depended recipes can build

or dependency inconsistencies like mentioned here:
https://github.com/conan-io/conan-center-index/issues/1737

also, for example, where is the sweet spot where recipes should be spitted, because handling multiple version in one script has limits in scaling.
For sure, as developer it is not a problem to add a level of indirection , some if here, some there, and trash in what you need now on your machine. But how does this recipe look too new users ....?

Supported platforms, what about iOS and Android support
It is mentioned in the conan docs, but then its passed to the users, and there are meanwhile several that have island solutions.

Are these all points that are not of interest?

[jgsogo]

Hi, @a4z

You are totally right on your concerns, and we would love to have an answer to all these topics:

• static by default: more specific issues are opened and we are working on it. Adding a _hook_ will be easy. 👍

• breaking changes in recipes (POV consumers): not only because of an option, but because of CMake targets names,... we have introduced some features in Conan to make it possible to mimic current CMake modules, I would expect existing recipes to become more and more stable (and new ones to be correct from the beginning). We would love not to break. If this is really a pain, you can use your own server or you can list the specific recipe revision you want to use (zlib/1.2.11@#<recipe-rev>), and update only on demand.

  To alleviate this issue (or to realize about some changes) I would like to add more test_package directories to every recipe, so we can check more Conan generators or different scenarios and be sure that we are not breaking without noticing. This is in the backlog.

• breaking changes in recipes (POV depending recipes): building all the dependencies is a big problem, we need to figure out what we want to do and then we will add something to the backlog:

  If we build everything in the PR, it will take a lot of time every commit to a PR, and probably the author deserves feedback as fast as possible.

  An alternative would be to build nightly, to build all the graph continuously and report failures (a bot opening issues): build systematically everything or choose recipes and profiles at random. It depends on how long it takes to build everything, or maybe we just need to run the test_packages, we don't need to build the actual library.

• Recipes growing in complexity. I totally agree with you and this is one of my biggest concerns right now: when to split the recipes. TBH, I need to have a look at recipes and check which ones are getting complex.... but I really don't have time for this task at the moment 😞

• Other platforms. Yes, I would like to start to use the two profiles approach to build recipes in Conan Center (for sure when it becomes the default in Conan client), and this together with having several test_package directories is one of the reasons why we are doing a lot of refactoring in the backend. My plan is:

  • Conan v1.x: keep using the current approach with the single profile (this is important, we need to know that the default works). When Conan v2.0 arrives, we will use two profiles.
  • Run some more builds with two profiles (cross-compiling) and report the status of those builds (they won't make the job fail, but at least the PR author knows if they are working).

All these issues are very important to us, and I can promise you that we try to do our best, we are very motivated about it and we'd really love to be able to solve all of it. For some of these topics, we (more or less) know what to do but we don't have enough time, other topics we really don't know which one is the best solution or we don't have any proposal yet. We really appreciate all your feedback and we love to hear from you about new problems, suggestions, and concerns.

Thanks for all your feedback, and thanks to everyone contributing to ConanCenter. We try to keep the pace with everything, but it is impossible 😄