Hi Max, Thorsten,
On Tue, Oct 31, 2017 at 11:11:23PM +0100, Thorsten Alteholz wrote:
On Tue, 24 Oct 2017, Max wrote: if there is a SONAME change, the package name should change. The link in the dev package should point to the new version. And ...
The library package named libosmonetif3.install According to https://wiki.debian.org/TransitionBestPractices it should be renamed to libosmonetif4.install because we're changing "current" component of libversion.
... yes, this as well (not only this file but all others that belong to this package as well)
... which is BTW what is more or less obvious and what I did for all the releases for the osmocom:latest feed that I created on the weekend.
We should also change debian/control to reflect this rename, but what about "Conflicts:" in there? I've tried reading https://debian-handbook.info/browse/stable/sect.package-meta-information.htm... but still not sure how it should be applied in case of shared libraries.
Shall we put libosmonetif3 in Conflicts? Both libosmonetif3 and libosmonetif2? Shall we use /Replaces instead? If so, for which version(s)?
Replaces: is only for two packages with the same functionality, so a Conflicts: would be right. It should be for each version available earlier (there might be an old version left during an upgrade).
Why would it conflict? The point of having the LIBVERSION "current" as part of the .so name is that you can have both installed at the same time, and that applications are linked against a specific version. So let's say I have an incompatible older version of the library installed, some older programs can still use it, while the newer library is used by newer / newly linked applications.
I see situations like this quite normally on any debian system:
ii libreadline5:amd64 5.2+dfsg-3+b1 amd64 GNU readline and history libraries, run-time libraries ii libreadline7:amd64 7.0-3 amd64 GNU readline and history libraries, run-time libraries