On Tue, Apr 14, 2009 at 04:16:32AM -0400, Robert Edmonds wrote: > your M-F-T is broken, followups to an existing bug report should not > also be sent to sub...@.
gah, sorry. I hope this time it will be right. > > Mail-Followup-To: Robert Edmonds <[email protected]>, > > [email protected], > > Debian Bug Tracking System <[email protected]> > > 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. You're right, I was only referring to the fact that libprotobuf and libprotoc do not follow the same SONAME. > 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++. This might be the case indeed. I though upstream has said so, but I can't find a thread about it... ah yes, see here: http://groups.google.com/group/protobuf/browse_thread/thread/930fb840bd5b1441/267e95241832a4c4 This means that there'll be a lot of churn always for these packages. > > 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: (I will, thanks) > 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. The main reason I chosed to have a single library package was to not have too many small packages, and per the above thread, upstream "intends" to keep them in sync. Also, libprotoc is/should only be used by the protobuf compiler, and not by external users, so I thought shipping it in the libprotobufX package is fine. As far as I can understand, your point is that upstream is never guaranteed to do so, and in order to prevent future problems it's better to split the packages? I also see other library packages providing multiple libraries (e.g. libssl0.9.8), so how "hard" is this rule? > 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. Good point. I guess we'll see when such a version is released. Thanks a lot for the information. iustin -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
