Bug#1055857: transition: opm-common
Hi,
Am Thu, Nov 23, 2023 at 09:32:31AM +0100 schrieb Sebastian Ramacher:
On 2023-11-12 21:42:20 +0100, Markus Blatt wrote:
Dear Debian release team,
A new upstream release of OPM is available. To ease migration to testing I am
requesting a mini-transition. Uploading to unstable would probably work even
without a transition, but I would like to play it safe.
This should only affect the OPM source packages opm-common, opm-grid, opm-
models, opm-simulators and opm-upscaling.
I have already uploaded new versions to experimental that seemed to have built
without any issues, see [1].
(please explain about the transition: impacted packages, reason, ...
for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions)
Ben file:
title = "libopm-common-2023";
is_affected = .depends ~ "libopm-common-2023.04" | .depends ~ "libopm-
common-2023.10";
is_good = .depends ~ "libopm-common-2023.10";
is_bad = .depends ~ "libopm-common-2023.04";
libopm-common has a Provides: libopm-common-X, but the shared library
included in libopm-common also has a SONAME of libopm-common.X. Why is
the packaging not following the common practice of matching the package
name with the SONAME?
Thanks a lot for noticing.
Indeed the library has an SONAME, but as upstream does not care about API
changes, one cannot rely on them. Basically the SONAME is changed
with every release. Releases happen twice a year in April/October. Hence
we have 2022.04, 2022.10, 2023.04, 2023.10, etc. The problem probably is
that there is no compatibility between 2023.04 and 2023.10. If we would do
intermediate snapshot releases, then those might have slightly incompatibe APIs,
too.
The reason for the current situation probably is a combination of lack of
knowledge on my side and inspiration taken from libdune-common-dev. I now
realise that the situation is different here, though.
Solving the SONAME issue might require quite some additional work. We would need
to start with 2024.0 now and increase the major number with every release. If
we do this only in Debian then those numbers would also differ from upstream,
which might be a problem.
What would your suggestion be?
Cheers,
Markus
Reply to: