your M-F-T is broken, followups to an existing bug report should not also be sent to sub...@.
> Mail-Followup-To: Robert Edmonds <edmo...@debian.org>,
> 523...@bugs.debian.org,
> Debian Bug Tracking System <sub...@bugs.debian.org>
Iustin Pop wrote:
> Unless upstream is not consistent in bumping the SONAME, see below.
> I agree that libprotobuf3/libprotobuf2 have no files in common, however
> this was not the case for the libprotobuf2/libprotobuf0 case, where they
> had in common libprotoc.so.0/libprotoc.so.0.0.0; upstream has not been
> very consistent in declaring the SONAME.
i see nothing inconsistent in upstream's SONAMEs.
the history of upstream's -version-info parameters is as follows:
* in r2, libprotobuf and libprotoc were imported with -version-info
0:0:0.
* in r46, libprotobuf was bumped from 0:0:0 to 2:0:0.
* in r79, libprotobuf was bumped from 2:0:0 to 3:0:0.
* in r79, libprotoc was bumped from 0:0:0 to 3:0:0.
* in tags/release-2.0.1, libprotobuf and libprotoc were set to
-version-info 0:0:0.
* in tags/release-2.0.2, libprotobuf was set to 2:0:0.
* in tags/release-2.0.2, libprotoc was set to 0:0:0.
* in tags/2.0.3, libprotobuf was set to 3:0:0.
* in tags/2.0.3, libprotoc was set to 3:0:0.
i haven't checked to see if the libprotoc 0:0:0 in the 2.0.2 release is
really compatible with the libprotoc 0:0:0 in the 2.0.1.
the only strange thing is perhaps that the ABIs are being broken on
almost every release. perhaps this is because the libraries are written
in C++.
> For libprotobuf3, just removing the conflicts (no files in common) and
> replaces (not same SONAME) will be OK, but if upstream ever does a mixed
> (libprotobuf bumped SONAME, libprotoc same SONAME) release again, these
> two libraries will have to be split, right?
libprotobuf and libprotoc are separate libraries and should be in
separate packages.
you should read the debian library packaging guide. in particular, it
says:
There are packages like libc6, which contain multiple shared
libraries in one package. This is not encouraged. [2] It becomes
more complex and more difficult to handle complex upgrade patterns.
bug#141275, omniorb package contained several different libraries
with different SONAME version numbering policies.
There has been a history of packages which were named with the
source package name, but it is better practice to name the package
according to the library name, for consistency. Some old packages
are not named this way, such as aalib-dev, but new packages should
follow the scheme of using the library SONAME.
For an example of a package which migrated from single-package
library file, see xlibs. xlibs in Debian 3.0 was one package
containing many shared libraries, and it is split into multiple
packages in later releases of Debian.
[2] This is the case unless it is confident that shared libraries
will not change interfaces independently, or compatibility issues
are carefully handled. In general, when shared libraries are split,
there is no reason upstream will keep changes to interfaces
synchronised.
based on the fact that upstream skipped a few current interface numbers
(0-2 and 0-3) they may be trying to somehow synchronize the current
number with the release (2.0.2, 2.0.3). but this is not guaranteed to
always be the case and they will probably stop if they release a
version >= 2.1.
--
Robert Edmonds
edmo...@debian.org
signature.asc
Description: Digital signature
