On Wed, Nov 30, 2022 at 6:21 PM Daniel Alley <dalley(a)redhat.com> wrote:
> Do I really need to explain this point? I think linking against system
> OpenSSL is *way better* than statically linking to a random vendored
> copy of it.
There are maybe about 100-120 libraries for which this is obviously the case. openssl,
glibc, glib2, zlib, libxml2, libcurl, kde libraries, etc. Core system libraries that
pretty much everything depends on. Dynamically linking such libraries has real benefits.
For everything else though? No, not so much.
These are actually all good examples of stuff that we dynamically link to.
This is the (not 100% exhaustive) list of system libraries we always
dynamically link to:
- all GTK / GNOME libraries (dbus, freetype, fontconfig, atk,
gdk-pixbuf, gdk, gtk3, gtk4, gio, glib2, graphene, gsk4, pango, cairo,
gstreamer, etc.)
- multimedia codecs / libraries (aom, dav1d, pipewire, pulseaudio, etc.)
- crypto libraries (openssl, libsodium, nettle, curl)
- compression libraries (bzip2, flate2, libz, lzma, zstd)
- database connectors (libsqlite, libpq)
- low-level device / storage libraries (devicemapper, libblkid)
I think almost all of these qualify as "Core system libraries that
pretty much everything depends on.".
Building their C dependencies from vendored copies (if that is even
supported) and statically linking them seems like a pretty bad idea in
almost all cases here, especially for things where the version of a
program on the "host" and the accompanying shared library should
match.
The only exception (that I know of) for "crate dependency built from
vendored sources and statically linked" in Fedora right now is
libgit2, because the version in Fedora is chronically outdated, and
dealing with that has become very painful - and started to block some
necessary updates to support more recent versions of Rust / cargo.
I feel like there is insufficient recognition of the extent to which
C libraries do "bundling". Not "bundling" in the sense of vendoring a
whole library, but in the sense of including one-off implementations of basic data
structures, configuration parsers, hashing algorithms, etc. I would love to hear anyone
argue that 100 different variations of "sha256.c" across 100 different packages
better follows the spirit of the "no bundling" guidelines than a vendored crate
named "sha256" with 100x as many eyes on it, and a higher likelihood to actually
be updated if a problem is found.
Many of the tiny, "sprawling" Rust dependencies are like this - not all of them
of course, but many.
But ... none of these "tiny" Rust crates are dynamically linked in
Fedora anyway - because Rust doesn't really support that?
So I fail to see your point there, unless you meant to say "C projects
don't 'bundle', they just often 'copy' some code into their
projects"?
Fabio