On Wed, Nov 30, 2022 at 6:21 PM Daniel Alley <dalley@xxxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
