On Fri, 5 Mar 2021 10:34:06 +0100, Sebastian Ramacher <sramacher@debian.org> wrote: > On 2021-03-04 07:06:05, Stephen Kitt wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian.org@packages.debian.org > > Usertags: binnmu > > > > Dear release team, > > > > libzstd1 used to provide an over-enthusiastic symbols file, which has > > resulted in dependencies which are too relaxed. The library API isn’t > > determined by its exported symbols, unfortunately, but by one of its > > headers. See https://bugs.debian.org/969597 and > > https://github.com/facebook/zstd/pull/2501 for details. > > > > As a result, a (small) number of packages have picked up a dependency > > on “libzstd1 (>= 1.3.8)” when it should be “(>= 1.4.0)” — they were > > built with one of the 1.4 packages, but the symbols file declared some > > of the 1.4 functions as available in 1.3.8 (which they were, > > technically, but with a different API in some cases). > > Please explain. If they were available with a different API prior to > 1.4, that sounds like an ABI break to me. In that case, the binNMUs > would just hide the problem. They weren’t intended to be available as part of the library API. libzstd distinguishes two sets of functions: one intended for use by programs linked with the dynamic library, another intended for use by programs linked statically. Programs built in Debian abide by this rule and don’t use any symbols they shouldn’t. Unfortunately, the way the library is built means that “static-only” symbols are still exported by the dynamic library (even though no dynamically-linked program uses them). The symbols file appears to have been generated mechanically, and as a result it includes symbols starting from the point where they appeared in the library, and not when they officially became part of the library’s API. The result is that programs built against libzstd 1.4.0 or later, using symbols added in 1.4.0, end up with a dependency on libzstd 1.3.8 or later, even though libzstd 1.3.8 doesn’t support the API they use. The point of the binNMUs is to fix the latter, by ensuring that packages depending on libzstd 1.4.0 or later really get an appropriate version of libzstd. Without this, users can end up with broken packages if they only partially upgrade their system. I’m working on a longer-term fix with upstream, see https://github.com/facebook/zstd/pull/2501 for details. I’ve already substantially reduced the number of exported symbols (which were never part of the external API and aren’t used by external users) in 1.4.9 upstream. Arguably this is a soname breakage, but the case can also be made that it isn’t: libzstd1 *is* backwards-compatible with all programs built against older versions, even though some of its exported symbols changed their API (they weren’t used in the incompatible versions). The invalid dependency declaration is a consequence of Debian packaging only, IMO. The shlibs file in the current package in unstable follows upstream’s instructions. Regards, Stephen
Attachment:
pgpTfBaE_1dQP.pgp
Description: OpenPGP digital signature