First rule of C package managers on Linux: "wrap distro package manager or GTFO". This doesn't seem to abide by that, at least from scrolling through the FAQ. I might've missed something though.
Coincidentally, distro packages are reproducible for good distros these days.
> 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.
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.
Coincidentally, distro packages are reproducible for good distros these days.
I don't think anyone follows your "rule" because it would be such a mess.
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.