Bug#888705: abseil-cpp packaging
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
<bbaren@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).
Reply to: