Re: Package dependency versions and consistency
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).
Reply to: