On Tue, 30 Jun 2020 at 10:51:39 +0200, Chris Hofstaedtler wrote: > I'm not sure it was a good idea before. Is static linking something > you actively want to support for glib?
It has worked in the past, Policy says the static library "is usually provided", and we occasionally get bug reports from people who want to link random libraries statically, so I didn't feel comfortable with unilaterally disabling it for no particular reason. The autopkgtest is there partly because things we don't test usually don't work, and partly because static linking to libmount regressed during GLib's move from Autotools to Meson (the pkg-config metadata in GLib was wrong); I added it to confirm that the regression fix had been effective. If I'm disabling the static library because dependencies no longer support it, then I can redirect bug reporters to the dependency and let them argue their case there if they want to (as with libdbus, which can't be linked statically any more due to libsystemd). People occasionally try to change Policy to say that static equivalents of shared libraries are definitely optional, or even that they are discouraged, but this never reaches consensus, because someone always appears and says "well actually, I rely on Debian shipping shared libfoo and libbar for armhf so that I can statically link them into a binary for my embedded frobnicator device, which (has glibc from 2005|doesn't have glibc|doesn't have space for glibc|...)". The obvious counterpoint that solving this is not really Debian's job is rarely effective. It is technically possible to link just the top of a dependency stack statically (for example a GLib program with static GLib and libmount, but dynamic libcryptsetup and glibc), but pkg-config doesn't make this straightforward and in practice it requires hard-coding paths to static libraries, so the autopkgtest in GLib doesn't attempt to exercise this. smcv