❦ 24 mars 2020 16:30 -07, Russ Allbery:

> On the other hand (and I don't follow this community closely, so apologies
> if I have the details wrong here), my impression is that the Go community
> is not planning to support shared libraries, loves its staticly-linked
> binaries, and makes extensive use of the fact that different packages can
> pin to different versions and this doesn't matter for their intended
> output format (a static binary).

Go supports shared libraries but I don't think it's widely used.
Notably, the tooling around it is quite primitive.
>
> Trying to shoehorn the latter into a shared library update model is almost
> certain to fail because it's working at intense cross-purposes to
> upstream.
>
>> This isn't necessarily such a new thing - the scale is new, but the
>> practice isn't. There are several C/C++ libraries in Debian that are
>> specifically designed to be vendored into dependent projects (either
>> because they are not API-stable or to simplify dependency management),
>> like gnulib (which exists as a package, but I think it's only there to
>> facilitate vendoring bits of it?), libstb (which does exist as a
>> separate package with a shared library, but I don't have a good picture
>> of how API- and ABI-stable it is), and libglnx.
>
> Indeed, I have a package, rra-c-util, which is vendored into every C
> package that I personally maintain and package, because it's my version of
> gnulib plus some other utility functions.  I recognize the potential
> concern should a security vulnerability be found in any of its functions,
> and accept the cost of providing security updates for every one of my
> packages that use it.  This still is, in my opinion, a better maintenance
> choice, not so much for Debian but for many non-Debian users of those C
> packages who do not want to (and often get confused by trying to) install
> a shared library as a prerequisite to installing the thing they actually
> care about.  (Also because, like gnulib, rra-c-util consists of a lot of
> different pieces, most of which are not needed for any given package, and
> includes pieces like Autoconf machinery that are tricky to maintain
> separately.)

-- 
This night methinks is but the daylight sick.
                -- William Shakespeare, "The Merchant of Venice"

Attachment: signature.asc
Description: PGP signature

Reply via email to