[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#984487: marked as done (nmu: libzstd1 rdeps relying on 1.3.8)

Your message dated Sun, 7 Mar 2021 18:12:21 +0100
with message-id <YEUJdRGvtjLqu6Ij@ramacher.at>
and subject line Re: Bug#984487: nmu: libzstd1 rdeps relying on 1.3.8
has caused the Debian Bug report #984487,
regarding nmu: libzstd1 rdeps relying on 1.3.8
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
984487: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984487
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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).

To fix this, would it be possible to binNMU the following? The version
of libzstd1 no longer provides a symbols file and relies on shlibs to
provide the correct dependency.

nmu badger_2.2007.2-2 . ANY . unstable . -m "update libzstd1 dependency"
nmu burrow_1.2.1-2 . ANY . unstable . -m "update libzstd1 dependency"
nmu cadvisor_0.38.7+ds1-2 . ANY . unstable . -m "update libzstd1 dependency"
nmu garagemq_0.0~git20200204.15e6a9d+ds-3 . ANY . unstable . -m "update libzstd1 dependency"
nmu lammps_20210122~gita77bb+ds1-2 . ANY . unstable . -m "update libzstd1 dependency"
nmu libarchive_3.4.3-2 . ANY . unstable . -m "update libzstd1 dependency"
nmu libdrpm_0.5.0-2 . ANY . unstable . -m "update libzstd1 dependency"
nmu mmllib_12-113e3+ds-3 . ANY . unstable . -m "update libzstd1 dependency"
nmu mysql-8.0_8.0.23-3 . ANY . unstable . -m "update libzstd1 dependency"
nmu rsymphony_3.2.3-4 . ANY . unstable . -m "update libzstd1 dependency"

Regards,

Stephen


-- System Information:
Debian Release: 10.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'), (100, 'unstable-debug'), (100, 'testing-debug'), (100, 'unstable'), (100, 'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

--- End Message ---
--- Begin Message --- 
On 2021-03-06 16:04:57 +0100, Stephen Kitt wrote:
> 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.

Thanks, binNMUs scheduled.

Cheers
-- 
Sebastian Ramacher

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: