On 29.12.20 23:39, Josh Triplett wrote: > 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).
Interestingly enough this is also growing discontent in the C++ community around ABI stability holding them back (e.g. [1] but that's by far not the only such opinion). I would have liked to make the ability to binNMU more accessible (similar to the give-back self-service), however I'm now somewhat convinced that we need no change source-only uploads, preferably performed centrally by dak. And you need to be able to supply build ordering constraints. I do wonder if delta downloads of .debs would really help, though. Even though individual builds might be reproducible the same is not necessarily true across independent uploads. So at least for final applications, with optimizations like LTO, it seems not that useful. For the lot of small helper packages in between it might help but then the delay is often to grab that off the mirror's disk and a delta scheme might only make that worse. Kind regards Philipp Kern [1] https://cor3ntin.github.io/posts/abi/
