On Tue, Dec 29, 2020 at 03:19:30PM +0200, Adrian Bunk wrote: > [...] Rust [...]
I did not bring up Rust, nor was I referring to Rust specifically, nor am I speaking for either Rust upstream or the work of the Rust team in Debian. There are *multiple* ecosystems in which the equivalent of shared-library dynamic linking either doesn't exist or has substantial drawbacks, including WebAssembly, JavaScript "compiled" bundles (not related to vendoring), Go (-dynlink is still experimental), Haskell, C++ "header-only" libraries, and various others. It's possible to get a sample of such cases by looking through the output of grep-dctrl -FBinary -sPackage,Binary --pattern=-dev /var/lib/apt/lists/*Sources for packages that ship a -dev package and don't ship a shared library package. There are *many* such packages already. We need an actual solution for rebuilding reverse-dependencies when needed. And again, static linking is not the problem I was hoping to address with this thread. > would first have to implement themselves whatever is needed to provide > security support. 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. 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. As this subthread has entirely diverged from that issue, I don't plan on responding further here, and I'd like to drop this subthread if at all possible. > With semver the API is already guaranteed to be 100% backwards > compatible with all previous releases implementing the same semver. > Why don't you use this guarantee to build a libxyz.so.2 for semver xyz-2? API is not ABI, and in many ecosystems (including but not limited to Rust), a library is more than just a set of symbol names pointing to compiled machine code. For instance, libraries can include generics, compile-time code generation, constant functions evaluated at compile-time, code run by build scripts, macros, and a variety of other things that get processed at build time and can't simply get pre-compiled to a symbol in a shared library. It may be possible, in the future, to carefully construct something like a shared library using a subset ABI, but doing so would have substantial limitations, and would not be a general-purpose solution for every library. It *might* be a viable solution for specific libraries pre-identified as being particularly likely to require updates (e.g. crypto libraries).