Advice on libtse3
Hi,
I recently adopted libtse3. Since then I've been trying to figure out
what to do about some rather ugly things about the package. One of
them involves things I'm not as familiar with as I maybe should be, and
I'd like some advice on the best way to resolve it.
Here's the situation: libtse3 is currently provided as a static
library only. This is because libtse3's upstream does not provide a
soname version number. Note: I don't mean that the soname version
sometimes doesn't track binary compatibility correctly -- I mean that
there simply is no soname version at all in the link command. Neither
-version-info nor -release is specified.
libtool "fixes" this omission by using a default soname, libtse3.so.0,
but I'm sure you won't be surprised when I tell you that upstream has broken
binary compatibility on at least one occasion that I know of (and I doubt
that was the only case).
One of my first acts as the new tse3 maintainer was to email upstream
and ask whether they had any plan to start using soname versioning; I
have received no reply to that email message. I know that previous
efforts to talk with upstream on this subject have not been successful
(at least, I think there were previous efforts, and their non-success is
obvious by examining the latest version of tse3). I sent another email
message in the last few days, but I'm not holding my breath for an
answer.
Obviously, the current situation is not desirable. I'd like to improve
on it by providing a shared library for tse3, but I have to deal with the
fact that upstream might not care about soname issues. I'd like to know
which of the following options is least objectionable, and whether there's
an option I haven't thought of.
(a) Create a libtse3 soname which increments with every upstream
release, possibly by encoding the upstream version into the soname.
The library packaging guide gives an example of openssl.
This would mean we are not binary-compatible with other
distributions. However, other distributions which include libtse3 are
already (probably) not binary-compatible with us if they have a
different upstream release of the library. It seems to me that this
is the least of the evils.
(b) Provide libtse3 with the "default" soname, but put:
libtse3 0 libtse3 (= $CURRENT_VERSION) in the shlibs file.
This should ensure that Debian packages work, but third-party
software could be broken by upgrades of libtse3.
(c) Leave things as they are: no shared libtse3.
I would like to avoid this unless all the alternatives are worse.
(d) Properly maintain the soname myself: analyze all upstream changes
for ABI breakage and update the soname if necessary.
This is fantasy -- I don't have the time to be a second upstream for
the package. (I could orphan it, but it appears that everyone else is
less interested in it than I am, judging from how long it spent
orphaned previously)
Daniel
--
/------------------ Daniel Burrows <d.burrows4@verizon.net> ------------------\
| Imagine if every Thursday your shoes exploded if you |
| tied them the usual way. This happens to us all the |
| time with computers, and nobody thinks of complaining. |
\------------- Debian GNU/Linux http://www.debian.org -- Because. ------------/
Reply to: