Reproducible and traceable configuration for Conan C and C++ package manager(blog.conan.io)
blog.conan.io
Reproducible and traceable configuration for Conan C and C++ package manager
https://blog.conan.io/cpp/conan/configuration/reproducibility/lockfile/2026/02/17/Reproducible-Configuration-Conan.html
12 comments
What if you want a library that isn't available in every distro? Or a specific version of a library?
I don't think anyone follows your "rule" because it would be such a mess.
I don't think anyone follows your "rule" because it would be such a mess.
> What if you want a library that isn't available in every distro? Or a specific version of a library?
Then your wrapper builds a native package for that first. After all it is building a native package for your application next, why would it be unable to also build a package for that library?
> I don't think anyone follows your "rule" because it would be such a mess.
Everyone offering distro repos is building packages like that, and that's a lot of projects.
Then your wrapper builds a native package for that first. After all it is building a native package for your application next, why would it be unable to also build a package for that library?
> I don't think anyone follows your "rule" because it would be such a mess.
Everyone offering distro repos is building packages like that, and that's a lot of projects.
The problem of packages not being packaged is not solved by more packaging systems.
The problem of libraries not being packaged is solved by distro-agnostic packaging systems. Why do you think everyone uses PyPI, Cargo, Go modules, NPM, etc. instead of this insane "package your app and all of its dependencies for every distro" idea? Pure lunacy.
It is not difficult to package for the most important distro (the others usually import from them). Those distro-agnostic packaging systems are popular because they basically have no quality control at all, so it is basically no effort to package for them, just register a github repository somewhere. But this is also why they are full of garbage and have severe supply chain issues.
> But this is also why they are full of garbage and have severe supply chain issues.
I don't think the solution to supply chain problems is "just make supplying things so shitty and annoying that nobody will bother". Not a good one anyway.
I don't think the solution to supply chain problems is "just make supplying things so shitty and annoying that nobody will bother". Not a good one anyway.
It's part of my job to ship software on Linux, and if anything the part making things "shitty and annoying" is when we have to deal with people/'suppliers' (exclusively) using "foreign" packaging methods.
We had 2 dependencies like that; one we talked to the creators about and helped them ship distro packages, the other we just got rid of. Life is nice now.
We had 2 dependencies like that; one we talked to the creators about and helped them ship distro packages, the other we just got rid of. Life is nice now.
I do not think packaging for a distribution is annoying. If you do not bother because you do not want to match some minimal community standards, maybe your software should no be packaged? And if you think the tooling can be improved, then why not invest there? But this does not justify the existence alternate packing systems.
sure, it is solved just by one with good packages coverage.
Using Linux since Slackware 2.0 in 1995, which rule?
use spack.io instead
Coincidentally, distro packages are reproducible for good distros these days.