[Bug 494148] Review Request: soci - The database access library for C++ programmers

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=494148





--- Comment #7 from Michael Schwendt <bugs.michael at gmx.net>  2009-04-06 13:40:44 EDT ---
> The diff between pristine 3.0.0 and your tarball is ~4 MB

I referred to "diff -Nur ..." of the two tarballs. The diff between the soci
upstream tarball and the soci subdir in your tarball is still ~2 MB. In either
case, this package is not SOCI 3.0.0 as found on their project site. ;-)


> For the SONAME, it seems to me cleaner to have one.

True, but upstream ought to be involved in deciding which soname to start with
_and_ which major library version to include in the soname.

Debian's soname scheme breaks the ABI everytime the library version and/or
compiler version is changed. With your own soname scheme, the burden of
maintaining ABI stability is solely on your shoulders.

$ rpm -qp --provides soci-mysql-3.0.0-2.fc10.i386.rpm | grep ^lib
libsoci_mysql.so.3

Plus, there is the risk that a future upstream release will conflict with your
sonames and soname versions. Perhaps they will restart at .so.3 while you are
at .so.4 already. Perhaps they will start at .so.0 or .so.1 for the first
stable API.

If sonames are made up, it's better to include the full product version in the
soname (e.g. libsoci_mysql-3.0.0.so.0 <- libsoci_mysql-3.0.0.so), which will
require rebuilds of dependencies everytime the version changes.

Consider joining forces with the Debian package maintainer.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.