Re: Split Packages files based on new section "buildlibs"
Simon McVittie <smcv@debian.org> writes:
> I think perhaps the key thing here is that Python does *have* a
> reasonably well-defined system-wide search path for packages outside the
> Python core (/usr/lib/python3/dist-packages). Even if some projects
> prefer to use pip instead of dist-packages, they can't claim that
> dist-packages doesn't exist.
Even more specifically, I think the critical difference is that software
written in Python (or JavaScript, or Java) consumes the packaged libraries
at runtime. If you have a Python application packaged for Debian, it uses
the Python libraries packaged for Debian when you run it.
This is *not* true for Go or Rust because the binaries are statically
linked. At runtime, no Go or Rust libraries are used by the binary
because they've already been linked into the binary. (My understanding is
that both support dynamic libraries to some extent but that they're
discouraged in both and not generally used.)
I think this is the critical difference and I'm not sure it's been
explicitly spelled out (although there have been a lot of messages in this
thread, so maybe I missed it).
Because of that, the packaged Rust and Go libraries are *only* useful for
building Rust and Go binaries, not for running them, and that's why it
matters that the Go and Rust build tools that Debian users would use don't
know how to, and don't want to, use installed versions of those libraries.
And thus this point:
> My understanding is that Rust and Go code literally doesn't have
> analogous built-in system-wide search paths for third-party libraries,
> and when building Debian packages that contain Rust and Go code, we have
> to invent them in a Debian-specific way.
Rust and Go both vendor dependencies during their build. Python isn't
really analogous; you *can* do something similar with virtualenvs, but (a)
Python doesn't really have a build the way that Rust and Go do because one
generally doesn't produce native code, and (b) the virtualenv approach is
optional and only one of many ways of assembling Python applications,
whereas there's largely only one way Rust and Go binaries are built.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: