Hi all, I have dropped almost all static (*.a)-files from libraries, which I maintain(ed). The main reason is the easier security fixes if any appear in the library. One need then basically rebuild the so-files. With statically linked code the security fixes are much harder: one need to rebuild all build-depends. Some more info [1].
ABI-breakage between LTS-releases is not a big deal. We should just change the SO-name of the library and force transition-process. [1] https://wiki.debian.org/StaticLinking#downsides Regards Anton Am Di., 18. Feb. 2020 um 02:46 Uhr schrieb Benjamin Barenblat <bba...@debian.org>: > > On Sunday, February 16, 2020, at 10:48 PM +0100, László Böszörményi (GCS) > wrote: > > In my reading abseil is _not_ guaranteed to have ABI compatibility at > > all times. That's why it meant to be a static library collection only. > > Forcing it to build shared libraries and have other packages than > > libabseil-cpp-dev is no sense I think. > > Abseil does reserve the right to break ABI at any time, and I can’t > speak to their future plans. But I think ABI breakages are unlikely to > occur in practice within an LTS release. If we wait and then package an > LTS release, I it’ll be completely reasonable to ship .so’s and .a’s. > > Relatedly, I think we should only package LTS Abseil for Debian. If > someone finds a CVE in Abseil, the Abseil team are going to want to > backport the fix to LTS releases; they’re not going to want to backport > it everywhere else. > > > @Benjamin: may you ask its developers to use the system gtest libraries > > if only ABSL_RUN_TESTS set to ON? > > Absolutely. I’ll bring it up with them at work tomorrow (today was a US > holiday).
