On Tue, Dec 29, 2020 at 02:39:04PM -0800, Josh Triplett wrote: >... > I've seen and experienced multiple times, in Debian, that it's dangerous > to start implementing solutions before first ensuring that they will be > accepted by whoever actually makes the call for what to adopt. Once > there are multiple acceptable solutions on the table, stepping up and > implementing one can help settle debate, but first there needs to be > some indication of which solutions will get accepted.
The number of acceptable solutions on the table so far feels more like a zero. > Hence trying to find a solution for one specific problem with the start > of this thread: it'd be substantially easier to address vendoring, if it > were at least possible to reliably upload small packages of individual > libraries, with the expectation that such packages would be accepted > even if small, un-bundled, and an additional semver-major version. >... To me this sounds like repeating old mistakes yet another time. In the C/C++ ecosystem the biggest problem with both vendoring and shipping several semvers of libraries is usually that this is extra work for our security team. This xyz_helper problem you gave also sounded like similar problems when shipping more than one semver of a C/C++ library. Decades of experience (relearned gazillion times the hard way) tell that what works best for a distribution is to ship one version of a library, and trying to push upstream libraries to the maturity where API+ABI are long-term stable. Accumulating more and more ancient semvers of a library just sounds like a bad idea, and this is what you get when software can use old semvers forever and semver making it easy for libraries to break API all the time. The last part is important to understand, a real problem is that 1. there is no incentive for library developers to spend the extra work for providing a stable API, and 2. there is no incentive for library users to spend the extra work for following upstream semver changes, and 3. there is no incentive for Debian maintainers to spend the extra work for pushing upstreams to improve if additional semver-major versions are permitted in Debian. To untangle this mess, there has to be a strict policy that there must not be more than one semver of a library in Debian. cu Adrian
