Please backport libzstd 1.3.1+dfsg-1 (universe) from artful

Bug #1717040 reported by Yann Collet on 2017-09-13
36
This bug affects 3 people
Affects Status Importance Assigned to Milestone
libzstd (Ubuntu)
Undecided
Andreas Hasenack
Nominated for Bionic by Andreas Hasenack
Xenial
Undecided
Andreas Hasenack
Zesty
Undecided
Andreas Hasenack
Artful
Undecided
Andreas Hasenack

Bug Description

[Impact]

 * libzstd v0.5.1 is an experimental version,
   which generates and read an experimental format
   incompatible with official libzstd v1+ format.

 * Backporting a newer version >= v1.0, such as artful's v1.3.1,
   fixes this issue

 * This backport/SRU is being requested by upstream.

[Test Case]

 * with the pristine package from each release, compress a big file. For example, /usr/bin/snap. Name the resulting compressed file according to the version that was used to compress it, like this:

Xenial:
$ zstd /usr/bin/snap -o snap.0.5.1.zst
Compressed 15528016 bytes into 4134889 bytes ==> 26.63%

Zesty:
$ zstd /usr/bin/snap -o snap.1.1.2.zst
/usr/bin/snap : 30.59% (10825608 => 3311295 bytes, snap.1.1.2.zst)

 * Upgrade to the package made available through this SRU and compress it again:

Xenial:
$ zstd /usr/bin/snap -o snap.1.3.1.zst
/usr/bin/snap : 25.11% (15528016 => 3899137 bytes, snap.1.3.1.zst)

Zesty:
$ zstd /usr/bin/snap -o snap.1.3.1.zst
/usr/bin/snap : 30.59% (10825608 => 3311290 bytes, snap.1.3.1.zst)

* Uncompress all the generated files using the new version. This proves it can handle files compressed by the old one:

Xenial:
$ zstd -d snap.0.5.1.zst -o snap.0.5.1
snap.0.5.1.zst : 15528016 bytes
$ zstd -d snap.1.3.1.zst -o snap.1.3.1
snap.1.3.1.zst : 15528016 bytes

Zesty:
$ zstd -d snap.1.1.2.zst -o snap.1.1.2
snap.1.1.2.zst : 10825608 bytes
$ zstd -d snap.1.3.1.zst -o snap.1.3.1
snap.1.3.1.zst : 10825608 bytes

 * Take md5sums of all uncompressed files and the original. They must of course match:

Xenial:
$ md5sum /usr/bin/snap snap.0.5.1 snap.1.3.1
0fa4fa69d79ef4685aaa93be5b3aa33f /usr/bin/snap
0fa4fa69d79ef4685aaa93be5b3aa33f snap.0.5.1
0fa4fa69d79ef4685aaa93be5b3aa33f snap.1.3.1

Zesty:
$ md5sum /usr/bin/snap snap.1.1.2 snap.1.3.1
ba0a3ef5f519688bc5b0b58f190e73a4 /usr/bin/snap
ba0a3ef5f519688bc5b0b58f190e73a4 snap.1.1.2
ba0a3ef5f519688bc5b0b58f190e73a4 snap.1.3.1

* Downgrade zstd back to the original version of the ubuntu release you are testing:

Xenial:
$ sudo apt install zstd=0.5.1-1

Zesty:
$ sudo apt install zstd=1.1.2-1 libzstd1=1.1.2-1

* Try to decompress the zst file created with the 1.3.1 version from the previous test. In xenial only, it should fail to recognize the format:
$ zstd -d snap.1.3.1.zst -o /dev/null
zstd: /dev/null already exists; do you wish to overwrite (y/N) ? y
zstd: snap.1.3.1.zst: not in zstd format

In zesty it should work:
$ zstd -d snap.1.3.1.zst -o snap.1.3.1-new
snap.1.3.1.zst : 9909192 bytes

* Still in zesty, compare the md5, which should match:
$ md5sum snap.1.3.1-new /usr/bin/snap
7c980688861eef598a56c7970d952028 snap.1.3.1-new
7c980688861eef598a56c7970d952028 /usr/bin/snap

[Regression Potential]

 * During transition, if some user switches to newer zstd version, and then send compressed data to another user has not yet updated zstd, the receiver will not be able to decompress as long as he does not update.

 * Note though that newer version contains a compatibility module which makes it able to read data generated by older versions, such as v0.5.1. Any existing document compressed with v0.5.1 will still be readable after update to v1.3.1.

[Other Info]

 * Linux kernel 4.14 now integrates zstd compression / decompression, primarily for BtrFS and SquashFS, with patches available for reiser4, zram, and initrd. Kernel version does not support compatibility module, hence cannot read data from v0.5.1. Userland tools associated with these services will fail if they link to Ubuntu LTS libzstd, as generating incompatible data.

 * On top of the incompatible format issue, libzstd v0.5.1 API is old and missing several features that applications relying on libzstd need, such as streaming interface, or bulk processing for dictionary compression.

--- Original description ---

Please backport libzstd 1.3.1+dfsg-1 (universe) from artful to xenial.

Reason for the backport:
========================
Current version in Xenial is v0.5.1,
it's an experimental version, using its own, incompatible format.
As a consequence, zstd on Ubuntu Xenial is not compatible with the rest of the world.

This is of important concern for products using libzstd as a shared library :
on Ubuntu Xenial, produced data is different, not compatible with v1+.

This issue has been made more pressing with the integration of zstd in Linux Kernel,
as userland tools must also be updated to read and generate zstd.

Note : this request was first improperly filled at : https://bugs.launchpad.net/zesty-backports/+bug/1717037

Testing:
========
Mark off items in the checklist [X] as you test them, but please leave the checklist so that backporters can quickly evaluate the state of testing.

Backport available from PPA:
https://launchpad.net/~ginggs/+archive/ubuntu/backports

* xenial:
[X] Package builds without modification (needs debhelper 10)
[X] zstd installs cleanly and runs
[ ] zstd-dbgsym installs cleanly and runs
[ ] libzstd1-dbgsym installs cleanly and runs
[X] libzstd-dev installs cleanly and runs
[X] libzstd1 installs cleanly and runs

No reverse dependencies

Related branches

Graham Inggs (ginggs) on 2017-09-20
summary: - Please backport libzstd 1.3.1 from debian
+ Please backport libzstd 1.3.1+dfsg-1 (universe) from artful
description: updated
Yann Collet (cyan4973) wrote :

Successfully tested 2 packages : zsdt, libzstd-dev, libzstd1

Yann Collet (cyan4973) wrote :

I meant "3" packages ...

description: updated
Graham Inggs (ginggs) on 2017-09-21
Changed in xenial-backports:
status: New → Confirmed
Yann Collet (cyan4973) wrote :

Any new on this backport ?

Yann Collet (cyan4973) wrote :

ping

David Britton (davidpbritton) wrote :

Hi Yann -- Why is -dbgsym untested?

Andreas Hasenack (ahasenack) wrote :

Given your arguments, we are tempted to make this an official SRU instead of a backport.

To help argue the case, could you come up with more detailed examples showing how the current version in xenial is incompatible with the world?

Some ideas:
- you said the kernel has incorporated zstd, do you have an example? Perhaps even better, an example that shows how zstd 0.5.1 in xenial is incompatible with what the xenial kernel (or hwe kernel for xenial) supports?
- can we demonstrate that zstd in xenial cannot decompress some zstd file compressed with the current upstream version? Perhaps a public file or URL somewhere even?

Here is a short discussion about the SRU possibilities for this package in #ubuntu-devel on freenode: https://irclogs.ubuntu.com/2017/12/06/%23ubuntu-devel.html#t19:53

Andreas Hasenack (ahasenack) wrote :

Oh, I must have done something wrong before, because zstd 0.5 did decompress a file compressed by 1.3 in my test. Now I can see that's not the case:

$ zstd -d snap.v1.3.zst -o decompressed #using zstd 0.5.1
zstd: snap.v1.3.zst: not in zstd format

So that shows files compressed with 1.3 cannot be decompressed by 0.5. That could be used as an argument *against* the SRU, though :) Do you have pointers showing that 0.5 was experimental, that things changed and that it should be dropped?

Checking the release notes, looks like v0.8 is the first release with the final compression format? https://github.com/facebook/zstd/releases/tag/v0.8.0

Yann Collet (cyan4973) wrote :

> Why is -dbgsym untested?

The PPA I tested did not contain these packages

Yann Collet (cyan4973) wrote :

Regarding format version :

- All versions < v1.0 are considered experimental. This used to be clearly labelled on the project's homepage, though it has been updated since then. zstd is only branded and supported by Facebook since v1.0.
- Technically, the compression format has been settled at v0.8.0, so all versions >= v0.8 are compatible with each other.
- zstd contains an optional backward compatibility module, which is enabled by default in both CLI and library. This module makes it possible for newer versions to read older versions, but *not the other way round*. Therefore, v1.0+ will be able to read data produced by v0.5.1, but v0.5.1 will not be able to read data from v1.0+.
- Note that the compatibility module is optional, and a number of projects have selected to not include it. Such projects are therefore unable to read data produced with v0.5.1. This includes, for example, the Linux Kernel codec (integrated in 4.14).

Hope it helps

Yann Collet (cyan4973) wrote :

Note that the format is an (important) part of the problem,
but there is also the topic of the API, which has changed much since v0.5.1.

The simplest prototypes are still the same (ZSTD_compress(), ZSTD_decompress()),
but advanced ones have evolved.
The streaming API is very different, and the older one, present in v0.5.1, is now considered deprecated (it generates compilation warnings, and in a future version, symbols will be removed).
The Dictionary API for Bulk processing doesn't exist.
Even minor details matter : all objects in zstd share a common pattern starting with ZSTD_createObject() and ending with ZSTD_freeObject(). For convenience, ZSTD_freeObject() accepts NULL pointers, like free(). But that's only true since >= v0.7.0, hence not in v0.5.1.

The API has stabilised in v0.8.1, adding only a couple of capabilities since, and guaranteeing continued support for existing interfaces labelled "stable" (all symbols published by default).

A number of applications expecting an API >= 0.8.1 will fail with libzstd v0.5.1, either at link stage, because a symbol is missing, or even sometimes at run stage, because a behaviour is different.

Changed in libzstd (Ubuntu):
status: New → Confirmed
no longer affects: libzstd (Ubuntu)
affects: xenial-backports → libzstd (Ubuntu)
description: updated
Yann Collet (cyan4973) wrote :

New template updated

description: updated
Andreas Hasenack (ahasenack) wrote :

Is the zesty version ok? 1.1.2?

Yann Collet (cyan4973) wrote :

Yes, it would be a pretty strong step forward compared to v0.5.1.

v1.1.2 is from December 2016 : https://github.com/facebook/zstd/releases/tag/v1.1.2

The main feature developed since then is multithreaded compression.
I guess a few users will miss it, but it's a minor setback compared to current situation.

PS : any reason why zesty's 1.1.2 would be preferable to artful's 1.3.1 ?

Andreas Hasenack (ahasenack) wrote :

I ask because otherwise we have to justify why we would be updating the zesty version (1.1.2) to artful's (1.3.1).

Andreas Hasenack (ahasenack) wrote :

It's a justification issue, and also trying to keep the general spirit of *Stable* Release Updates (emphasis mine). What problems would we be fixing by updating zesty's zstd from 1.1.2 to 1.3.1, and if they are worth such an update. If it's just multithreading capability, then I think we can skip zesty, given that artful has it and zesty will be end of life in about a month (Jan 2018).

Yann Collet (cyan4973) wrote :

Multithreading is the main new capability I can think of,
and that's probably the one users will miss the most,
but there are quite a few more ones, listed on the release page, and in the NEWS document :
https://github.com/facebook/zstd/releases
https://github.com/facebook/zstd/blob/dev/NEWS#L24

The list is pretty long though, and just copy/pasting it wouldn't give a sense of priority.
Let's say there are a lot of small improvements and little bug fixing contributing to an overall better experience. Given a choice, I would recommend v1.3.1 over v1.1.2.

Changed in libzstd (Ubuntu Xenial):
assignee: nobody → Andreas Hasenack (ahasenack)
Changed in libzstd (Ubuntu Zesty):
assignee: nobody → Andreas Hasenack (ahasenack)
Changed in libzstd (Ubuntu Xenial):
status: New → In Progress
Changed in libzstd (Ubuntu Zesty):
status: New → In Progress
Changed in libzstd (Ubuntu):
status: Confirmed → Fix Released
Yann Collet (cyan4973) wrote :

Any news on this update ?

David Britton (davidpbritton) wrote :

Hey Yann -- no news. Still in progress.

It's my next thing to do

On Dec 15, 2017 20:35, "David Britton" <email address hidden> wrote:

> Hey Yann -- no news. Still in progress.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1717040
>
> Title:
> Please backport libzstd 1.3.1+dfsg-1 (universe) from artful
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/libzstd/+bug/
> 1717040/+subscriptions
>

Andreas Hasenack (ahasenack) wrote :

Hmm, why did it have to require a newer debhelper...

I don't think an SRU can depend on something that's in backports. I will have to read up on "Standards-Version" and debhelper versions to see what I will have to change in the package to build properly with xenial's debhelper (version 9.x).

Andreas Hasenack (ahasenack) wrote :

Ok, after an analysis done by a core dev (thanks @paelzer!), I have a way forward with this.

Andreas Hasenack (ahasenack) wrote :
description: updated
Andreas Hasenack (ahasenack) wrote :

@cyan4973, may I change your first test case into something that won't involve a download/build/install cycle? I was thinking about just using the 0.5.1 version in xenial to try to decompress the 1.3.1 compressed file I created in the test I just added to the bug description. Something like this:

"""
* Downgrade zstd back to xenial's original version:

$ sudo apt install zstd=0.5.1-1

* Try to decompress the zst file created with the 1.3.1 version from the previous test. It should fail to recognize the format:
$ zstd -d snap.1.3.1.zst -o /dev/null
zstd: /dev/null already exists; do you wish to overwrite (y/N) ? y
zstd: snap.1.3.1.zst: not in zstd format
"""

Would that be ok, and still be in the spirit of this update?

Yann Collet (cyan4973) wrote :

@ahasenack : yes, completely

ChristianEhrhardt (paelzer) wrote :

Review on the MPs is complete and it is now sponsored for SRU review in [xenial/zesty]-unapproved.

description: updated
description: updated
description: updated
Robie Basak (racb) wrote :

Yann, thank you for the detailed analysis. This is very helpful in giving us confidence in making changes to the stable releases.

The addition of a libzstd1, and the update of zstd itself to use it, sounds reasonable to me.

An additional thing for Regression Potential though I think?

We're deliberately breaking the API provided by libzstd-dev in Xenial then, according to Yann's comment 10. If a user is relying on some local build against libzstd-dev then this proposed SRU will break it. We should call this out and make a decision on it. I presume Andreas and Yann are both in favor? I think this is what Adam was referring to in https://irclogs.ubuntu.com/2017/12/06/%23ubuntu-devel.html#t20:12 ? It doesn't sound counter to the intent to me. Any opinions on using libzstd1-dev in the SRU instead to mitigate this? Or are you asking to specifically not do that and change the API of libzstd-dev itself?

I'm not particularly worried about justifications for Zesty. It's about to go EOL anyway. Anything that is acceptable for Xenial should also be acceptable for Zesty unless I'm missing some particular case where the circumstances are different.

Yann Collet (cyan4973) wrote :

Hi Robie

As far as I can tell, it is much more likely that an application expecting zstd >=v1.0.0 will break, most likely at link stage, and maybe at run stage, when provided with v0.5.1 instead.
The other way round should be less problematic : applications expecting to work with v0.5.1 should still work with v.1.3.1.

The reason is :
All symbols defined in v0.5.1 are also present in the "stable" section of v1.3.1.

For reference, here is the API for v0.5.1 : https://github.com/facebook/zstd/blob/v0.5.1/lib/zstd.h
and here is the API for v1.3.1 : https://github.com/facebook/zstd/blob/v1.3.1/lib/zstd.h

The major counter example is the streaming API.
This one used to be available in a separate package :
https://github.com/facebook/zstd/blob/v0.5.1/lib/zbuff.h
It is clearly labelled experimental, hence does not provide any API stability guarantee.

Nonetheless, in v1.3.1, this API is still available here :
https://github.com/facebook/zstd/blob/v1.3.1/lib/deprecated/zbuff.h
It is the exact same API, defining the same symbols.
What has changed is that this API is now branded "deprecated", which means it will generate deprecation warnings during compilation (except if these warnings are explicitly disabled, using typically -Wno-deprecated-declarations for gcc, or the custom macro ZBUFF_DISABLE_DEPRECATE_WARNINGS).

The deprecation warnings include comments to invite users to migrate towards the new "stable" streaming API, defined here : https://github.com/facebook/zstd/blob/v1.3.1/lib/zstd.h#L248
Of course, this is only useful for developers.

Robie Basak (racb) wrote :
Download full text (3.4 KiB)

How about this:

1. Add transitional packages libzstd1-dev -> libzstd-dev in Artful and Bionic (no Conflicts).

2. Backport what is in Artful, but drop the transitional libzstd1-dev package, rename libzstd-dev to libzstd1-dev and have it Conflicts with libzstd-dev.

This will land after Zesty EOLs, so don't worry about Zesty.

This will result in:

The zstd CLI from the zstd package will be updated, linked against libzstd1 and using new wire protocol.

libzstd.so.1 will become available in Xenial. libzstd.so.0 will remain available.

libzstd-dev will continue to exist and will not change, with the latest version remaining in the release pocket.

libzstd1-dev will be added. Users will only be able to have either libzstd-dev or libzstd1-dev installed at once. The one installed will determine whether the old API or the new API is used, and whether the link will be against the old or new soname.

Users already building using libzstd-dev locally in Xenial will not break and will continue to be able to rebuild (ie. "stay green") without any required intervention. If they wish, they can choose to use libzstd1-dev in Xenial instead. Or they can switch to use a newer release of Ubuntu or build directly against upstream sources, which I think is more likely for this use case anyway. Switching to libzstd1-dev will require code changes due to the API change, but this way this won't be forced upon them.

Users building against libzstd-dev locally who switch to libzstd1-dev will be automatically transitioned to libzstd-dev again upon upgrade to Artful or Bionic. Users who hardcode the libzstd1-dev name in any automated builds will break after upgrading beyond Bionic, since we'll drop the transitional package at that point, so should really do something like "if release == Xenial: install libzstd1-dev; else install libzstd-dev" if they want to use a distribution provided library on Xenial *and* build against the newer wire protocol and library.

If a security or bugfix updates to libzstd.so.0 becomes required, we'll need to adjust the release pocket source package to build only the libzstd0 binary package at that time.

Yann: would you be happy with this?

Rationale:

There is an SRU policy exception "to adjust to changes in the environment, server protocols, web services, and similar". I think, under this exception, we want an SRU to cause the zstd CLI to produce new format output with backwards compatibility, and for libzstd.so.1 to be made available so that other third parties who link against the library we ship can do that also (we'd update other packages in the Ubuntu release too, but we don't have any in this particular case).

> It is clearly labelled experimental, hence does not provide any API stability guarantee.

Separate from an upstream guarantee though, Ubuntu _does_ try to ensure that stable releases do not change behaviour, except when it is deliberate and the project chooses to make an exception. This guarantee is separate from any upstream guarantees. A blanket policy by a distribution is much easier for users to rely upon versus individual upstream guarantees that may not all match. Part of the point of a distribution that does stable re...

Read more...

Yann Collet (cyan4973) wrote :

I have a feeling that I don't fully grasp all the implied side effects here,
so if this process feels safer based on your experience, please go ahead.

I don't think the API will be an issue in this upgrade : as stated, all published symbols in v0.5.1 are still published in v1.3.1, so I would expect such application to continue linking properly.

The change of format is another thing, and an application hardwired to deal with v0.5.x experimental format, if such a thing exist, would be surprised to deal with data using v1.x format. So some caution in the transition is indeed welcomed.

Andreas Hasenack (ahasenack) wrote :

Ok, I'll handle it with a new set of packages.

Graham Inggs (ginggs) wrote :

"...an application hardwired to deal with v0.5.x experimental format, if such a thing exist..."

@ahasenack: Isn't this precisely we have Ubuntu Backports?
We are saying:
here is a new version of this software
we have checked that it doesn't break anything in the archive
you need to opt-in to install it
and if you've built some local packages with it, you may have some breakage

Robie Basak (racb) wrote :

On Tue, Jan 16, 2018 at 07:37:15PM -0000, Graham Inggs wrote:
> "...an application hardwired to deal with v0.5.x experimental format, if
> such a thing exist..."
>
> @ahasenack: Isn't this precisely we have Ubuntu Backports?

I think we're somewhere in the middle.

AIUI, virtually nothing else in the wider ecosystem can consume output
produced by Xenial's zstd CLI tool. By publishing an update into
xenial-updates, we'd be recommending that users update to it
automatically (in practice the majority will get it without taking a
separate step) because the version released with Xenial is effectively
broken in terms of interoperability.

> you need to opt-in to install it

The point of considering an SRU for this fix, rather than backports, is
precisely to remove this requirement. Users expect broken stuff to be
fixed without having to individually opt-in to each fix, but instead by
installing general "updates".

I can see how this particular proposed update could go either way. But
right now, we seem to be swinging in the direction of releasing it as an
SRU, especially because we have a way to do that with no known downside.
Our existing SRU policy does permit an update as a result of a change in
the wider Internet environment. That we have an interop problem because
the zstd CLI produces output that can't practically be handled anywhere
else does, IMHO, qualify it for an SRU under this existing policy
permission. The question is if and how we do it in the face of
regression risk to existing users.

Comments welcome, but please frame the discussion in terms of what we're
trying to do and in terms of our existing SRU policy documented at
https://wiki.ubuntu.com/StableReleaseUpdates.

Andreas Hasenack (ahasenack) wrote :

Yeah, but the backports process is kind of broken and seeing no traction, that's why we are trying an SRU.

Andreas Hasenack (ahasenack) wrote :

I have some good results. Xenial first, and artful in a subsequent but comment.

XENIAL (details in the attached zstd-xenial.txt file):
starting with:
libzstd-dev 0.5.1-1
libzstd0 0.5.1-1
zstd 0.5.1-1

results in:
libzstd-dev 0.5.1-1
libzstd0 0.5.1-1
libzstd1 1.3.1+dfsg-1~ubuntu0.16.04.1~ppa3
zstd 1.3.1+dfsg-1~ubuntu0.16.04.1~ppa3

Installing the new 1.3.1 dev package results in the removal of the old one:
The following packages will be REMOVED:
  libzstd-dev
The following NEW packages will be installed:
  libzstd1-dev

which gives you:
libzstd0 0.5.1-1
libzstd1 1.3.1+dfsg-1~ubuntu0.16.04.1~ppa3
libzstd1-dev 1.3.1+dfsg-1~ubuntu0.16.04.1~ppa3
zstd 1.3.1+dfsg-1~ubuntu0.16.04.1~ppa3

RELEASE UPGRADE TO ARTFUL
a) starting with old 0.5.x dev package:
libzstd-dev 0.5.1-1
libzstd0 0.5.1-1
libzstd1 1.3.1+dfsg-1~ubuntu0.16.04.1~ppa3
zstd 1.3.1+dfsg-1~ubuntu0.16.04.1~ppa3

You end up with:
libzstd-dev 1.3.1+dfsg-1ubuntu0.1~ppa2
libzstd1 1.3.1+dfsg-1ubuntu0.1~ppa2
zstd 1.3.1+dfsg-1ubuntu0.1~ppa2

b) starting with new dev package:
libzstd0 0.5.1-1
libzstd1 1.3.1+dfsg-1~ubuntu0.16.04.1~ppa3
libzstd1-dev 1.3.1+dfsg-1~ubuntu0.16.04.1~ppa3
zstd 1.3.1+dfsg-1~ubuntu0.16.04.1~ppa3

You end up with:
libzstd-dev 1.3.1+dfsg-1ubuntu0.1~ppa2
libzstd1 1.3.1+dfsg-1ubuntu0.1~ppa2
libzstd1-dev 1.3.1+dfsg-1ubuntu0.1~ppa2
zstd 1.3.1+dfsg-1ubuntu0.1~ppa2

Andreas Hasenack (ahasenack) wrote :
Andreas Hasenack (ahasenack) wrote :

ARTFUL (details in the attached zstd-artful.txt file):

starting with:
libzstd-dev 1.3.1+dfsg-1
libzstd1 1.3.1+dfsg-1
zstd 1.3.1+dfsg-1

results in (no big deal):
libzstd-dev 1.3.1+dfsg-1ubuntu0.1~ppa2
libzstd1 1.3.1+dfsg-1ubuntu0.1~ppa2
zstd 1.3.1+dfsg-1ubuntu0.1~ppa2

installing the new libzstd1-dev transitional package changes nothing, as expected:
The following NEW packages will be installed:
  libzstd1-dev
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.

but removing libzstd-dev also removes libzstd1-dev:
The following packages will be REMOVED:
  libzstd-dev* libzstd1-dev*
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.

and if you start from nothing and install libzstd1-dev (the transitional package);
The following additional packages will be installed:
  libzstd-dev libzstd1
The following NEW packages will be installed:
  libzstd-dev libzstd1 libzstd1-dev
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.

you also get the "real" dev package, and the actual library.

I'll do the same layout for bionic.

Andreas Hasenack (ahasenack) wrote :
Changed in libzstd (Ubuntu Zesty):
status: In Progress → Won't Fix
Changed in libzstd (Ubuntu Artful):
status: New → Confirmed
status: Confirmed → In Progress
assignee: nobody → Andreas Hasenack (ahasenack)
Changed in libzstd (Ubuntu):
status: Fix Released → In Progress
assignee: nobody → Andreas Hasenack (ahasenack)
Andreas Hasenack (ahasenack) wrote :

I have to retest this. d-shlibmove (why is that needed btw? Never heard of this yet another helper) is complaining the libzstd1-dev has no provides for libzstd-dev.

Andreas Hasenack (ahasenack) wrote :

I repeated the tests with the xenial package having the extra "Provides: libzstd-dev" and saw no ill effects. Attaching the new txt files with the details.

Andreas Hasenack (ahasenack) wrote :
Andreas Hasenack (ahasenack) wrote :

This artful test now includes a release-upgrade run to bionic

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers