This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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.html 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
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)