Re: What problem might happen when bumping soname without adding Conflicts:/Breaks:?

[Russ Allbery]

Adrian Bunk  writes:

> The default in Debian is to allow coinstallation of the libraries,
> but there are actually cases where it is better to add a Conflicts.

> Without symbol versioning it is a problem if you end up with both 
> libraries in a binary, in this case e.g.:
>   deepin-menu -> libdframeworkdbus1
>   deepin-menu -> libdtkwidget2 -> libdframeworkdbus2

This is a good point, although if you don't have symbol versioning for a
shared library in this day and age, I'd say that itself is a bug.  But I
know there are upstreams who still haven't gotten the religion.

-- 
Russ Allbery (r...@debian.org)   

Re: What problem might happen when bumping soname without adding Conflicts:/Breaks:?

[Gert Wollny]

Am Donnerstag, den 29.03.2018, 21:43 +0300 schrieb Adrian Bunk:
> On Wed, Mar 28, 2018 at 08:08:07PM -0700, Russ Allbery wrote:
> > Boyuan Yang <073p...@gmail.com> writes:
> > 
> > > * Upstream released new version and bumped SONAME to 2
> > > * -dev package didn't change its name
> > > * My mentor suggests that the new library package
> > > (libdframeworkdbus2) should 
> > > add the relationship "Conflicts: libdframeworkdbus1"
> > 
> > You do not want to do that.  It defeats one of the primary purposes
> > for changing the package name: allowing both versions of the shared
> > library to be co-installed.
> > ...
> 
> The default in Debian is to allow coinstallation of the libraries,
> but there are actually cases where it is better to add a Conflicts.
> 
> Without symbol versioning it is a problem if you end up with both 
> libraries in a binary, in this case e.g.:
>   deepin-menu -> libdframeworkdbus1
>   deepin-menu -> libdtkwidget2 -> libdframeworkdbus2
Since the -dev package doesn't change name this can only happen in the
SO-name transition phase, and a binary rebuild of the reverse
dependencies will fix this since it will pull in only the latest
version, and AFAIK the release team scheduls this kind of rebuild of
reverse deps when a so-name transition is done.

> Even with symbol versions things can go badly in some cases,
> like the OpenSSL situation in stretch being a complete mess and
> in some cases using the wrong OpenSSL can result in your application
> just segfaulting (e.g. the libcurl API passes an opaque OpenSSL
> struct).
Well, openssl has/had two different -dev package, which made this
problem possible.

> OpenSSL is special due to two versions being supported in stretch,
> otherwise a Conflicts between libssl1.0.2 and libssl1.1 might have
> been a good solution.
But it would have meant for the user that they can notonly co-install
packages that depend on the same library version.

Best,
Gert 

Re: What problem might happen when bumping soname without adding Conflicts:/Breaks:?

[Adrian Bunk]

On Wed, Mar 28, 2018 at 08:08:07PM -0700, Russ Allbery wrote:
> Boyuan Yang <073p...@gmail.com> writes:
> 
> > * Upstream released new version and bumped SONAME to 2
> > * -dev package didn't change its name
> > * My mentor suggests that the new library package (libdframeworkdbus2) 
> > should 
> > add the relationship "Conflicts: libdframeworkdbus1"
> 
> You do not want to do that.  It defeats one of the primary purposes for
> changing the package name: allowing both versions of the shared library to
> be co-installed.
>...

The default in Debian is to allow coinstallation of the libraries,
but there are actually cases where it is better to add a Conflicts.

Without symbol versioning it is a problem if you end up with both 
libraries in a binary, in this case e.g.:
  deepin-menu -> libdframeworkdbus1
  deepin-menu -> libdtkwidget2 -> libdframeworkdbus2

Even with symbol versions things can go badly in some cases,
like the OpenSSL situation in stretch being a complete mess and
in some cases using the wrong OpenSSL can result in your application
just segfaulting (e.g. the libcurl API passes an opaque OpenSSL struct).

OpenSSL is special due to two versions being supported in stretch,
otherwise a Conflicts between libssl1.0.2 and libssl1.1 might have
been a good solution.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: What problem might happen when bumping soname without adding Conflicts:/Breaks:?

[Ondrej Novy]

Hi,

2018-03-29 4:35 GMT+02:00 Boyuan Yang <073p...@gmail.com>:

> * My mentor suggests that the new library package (libdframeworkdbus2)
> should
> add the relationship "Conflicts: libdframeworkdbus1"
>

what is mentor's argument about adding this?

>
> ...and such necessity is not reflected in the documentation.


which i consider correct.


> We'd like to know that with transitions for library soname bump, is
> "Conflicts:" relationship needed / not needed in all circumstances and what
> problem might users / developers encounter if it is added / not added.
>

If there are no file collision (and both packages can be co-installed), I
don't see any reason why add Conflicts/Replaces.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Re: What problem might happen when bumping soname without adding Conflicts:/Breaks:?

[Russ Allbery]

Boyuan Yang <073p...@gmail.com> writes:

> * Upstream released new version and bumped SONAME to 2
> * -dev package didn't change its name
> * My mentor suggests that the new library package (libdframeworkdbus2) should 
> add the relationship "Conflicts: libdframeworkdbus1"

You do not want to do that.  It defeats one of the primary purposes for
changing the package name: allowing both versions of the shared library to
be co-installed.

> ...and such necessity is not reflected in the documentation. My personal
> thought is that with "smooth updates" (as described in [1]), the old
> library and the new library (with different SONAME) should be able to
> installed simultaneously on any Debian Unstable / Debian Testing system
> without any problem during the transition.

Yup, exactly.

> If that is true, the "Conflicts:" relationship shouldn't appear. The
> "Replaces:" relationship [2] should not appear as well because there
> won't be any file conflcts.

Correct.

You never need Conflicts/Replaces for a normal library SONAME transition.

-- 
Russ Allbery (r...@debian.org)   

What problem might happen when bumping soname without adding Conflicts:/Breaks:?

[Boyuan Yang]

Hello debian-devel and mentors,

Recently I found a disagreement with my mentor about proper handling of 
library transition (bumping SONAME) and we agreed that we need some 
suggestions.

Transition documentation (written by Release Team) can be found at [1].

Some quick facts:

* We have a libdframeworkdbus1 with soname 1; it is a standard Multi-Arch 
library:

% dpkg -L libdframeworkdbus1 
/. 
/usr 
/usr/lib 
/usr/lib/x86_64-linux-gnu 
/usr/lib/x86_64-linux-gnu/libdframeworkdbus.so.1.0.0 
/usr/share 
/usr/share/doc 
/usr/share/doc/libdframeworkdbus1 
/usr/share/doc/libdframeworkdbus1/changelog.Debian.gz 
/usr/share/doc/libdframeworkdbus1/changelog.gz 
/usr/share/doc/libdframeworkdbus1/copyright 
/usr/lib/x86_64-linux-gnu/libdframeworkdbus.so.1 
/usr/lib/x86_64-linux-gnu/libdframeworkdbus.so.1.0 
/usr/share/doc/libdframeworkdbus1/CHANGELOG.md.gz

* Upstream released new version and bumped SONAME to 2
* -dev package didn't change its name
* My mentor suggests that the new library package (libdframeworkdbus2) should 
add the relationship "Conflicts: libdframeworkdbus1"

...and such necessity is not reflected in the documentation. My personal 
thought is that with "smooth updates" (as described in [1]), the old library 
and the new library (with different SONAME) should be able to installed 
simultaneously on any Debian Unstable / Debian Testing system without any 
problem during the transition. If that is true, the "Conflicts:" relationship 
shouldn't appear. The "Replaces:" relationship [2] should not appear as well 
because there won't be any file conflcts.

We'd like to know that with transitions for library soname bump, is 
"Conflicts:" relationship needed / not needed in all circumstances and what 
problem might users / developers encounter if it is added / not added.

Thank you very much.

--
Regards,
Boyuan Yang


[1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions
[2] https://www.debian.org/doc/debian-policy/#s-replaces

signature.asc
Description: This is a digitally signed message part.