Bug#888705: abseil-cpp packaging
On Tuesday, February 18, 2020, at 9:01 PM +0100, László Böszörményi (GCS) wrote:
> There's a compatibility page[1] what Abseil is and isn't. It states
> the following things.
> "We do not promise any ABI compatibility — we intend for Abseil to be
> built from source, hopefully from head. The internal layout of our
> types may change at any point, without notice."
> As I read waiting for LTS releases might be late (its head commit
> version advised to be used). I guess other Google applications other
> libraries commonly wants newer Abseil releases than LTS ones.
I think that’s accurate. The culture at Google emphasizes continuous
integration from head rather than coding against releases. However, this
isn’t just about Google applications. There are other F/OSS projects
that want to take an Abseil dependency and aren’t ready to commit to
that sort of development model – see, for instance,
https://github.com/darktable-org/rawspeed/issues/122 (“Stop reinventing
the wheel”), in which Darktable investigates taking an Abseil dependency
and decides to wait until the LTS story is fully hammered out. The
Abseil team understands that the F/OSS world expects stable ABIs;
they’re going to break ABI all over the place at head, but they’re not
going to go out of their way to break it within an LTS release.
> "Not all Abseil libraries are suitable for dynamic loading. Some
> libraries have startup/initialization requirements and may not be
> suitable for dynamic loading. We will try to be clear about which
> libraries are OK for dynamic loading. However we don’t generally
> deploy code in this fashion, mistakes are possible, [...]".
> That is, even shared libraries can be built, those are not guaranteed to work.
I don’t think we should shy away from providing functionality just
because upstream doesn’t guarantee it to work. It’s true that the Abseil
developers don’t test Abseil as .so’s, but testing exists in Debian for
a reason. If Debian ships an Abseil .so, and bugs appear in testing, we
can work with upstream to fix them or patch them ourselves if upstream
is nonresponsive.
I did discuss the initialization issues with an Abseiler today; he
doesn’t know the full story, but he knows somebody within Abseil is
working on making initialization more lazy (and therefore more
.so-compatible). If you’re interested, I can discuss that with them at
our next meeting and let you know what the story is.
> I think there should be a compatibility matrix or test if the latest
> LTS release is enough for most Google applications or those need newer
> versions (no new API added for recent application development).
Agreed – there should definitely be some testing involved.
For what it’s worth, the next LTS is likely to be cut from head before
the end of the week. For a little while afterward, at least, nobody
should need anything newer than what’s in the LTS.
On Sunday, February 16, 2020, at 10:48 PM +0100, László Böszörményi (GCS) wrote:
>>> @Benjamin: may you ask its developers to use the system gtest libraries
>>> if only ABSL_RUN_TESTS set to ON?
On Monday, February 17, 2020, at 8:21 PM -0500, Benjamin Barenblat wrote:
>> Absolutely. I’ll bring it up with them at work tomorrow (today was a US
>> holiday).
I spoke with an Abseiler today about this. He believes that Abseil
definitely needs to support that, but there’s still some
consensus-building that needs to happen within the team before we can
guarantee that upstream will take a patch for it. I have a preliminary
version of such a patch, and I’ll try to get it finished and sent in the
next day or two; that way, even if upstream lags taking it, we can
import it and get the support we need.
Reply to: