Re: potential tiff transition, tiff 4.0.0 strategy
* Jay Berkenbilt <qjb@debian.org> [111229 17:26]:
> Julien Cristau <jcristau@debian.org> wrote:
> > FWIW, I think it should be required for such a library to use versioned
> > symbols if it doesn't care to keep its ABI stable.
>
> While I agree in principle, this is the first ABI change in the over 10
> years since I've been using the library, and no others are planned for
> the foreseeable future.
The important aspect to look at when deciding whether versioned symbols
are needed is not how often the API changes, but if there are libraries
and plugins linking against this library.
Also note that symbol versioning only in the new version will not help.
One needs symbol versioning in the old version too any everything linked
against the old version being linked against the version with versioned
symbols (i.e. one would need an archive wide rebuilt and then only would
catch the distribution supplied binaries and not any user supplied ones).
The only other way is to make sure that nowhere the libraries can be
loaded into the same program in a harmful way (though almost every way
should be considered harmful unless proven otherwise, as there are not
that many guarantees about different symbols with the same name).
Or one has to make sure the two libraries do not share any incompatible
symbol name (ugly, as it usually involves #define orgies).
> I'm planning on uploading the new version to unstable but not having it
> provide libtiff-dev until I hear from the release time how the
> transition should be handled. That way at least those packages that are
> already including their own copies of the tiff 4.x source code can stop
> doing it, but there won't be any accidental dependencies on multiple
> versions.
The problematic part is any program that at runtime might somehow pull
in both binaries. Then it is more or less random which version is used
by which code. If there are libraries using this library and those
libraries are used in the same program (including used by plugins[1])
then one must make sure there is no way one ends up with a program
loading one version of the one library pullinging in the old and one
version of the other library pulling in the new version. (Including the
case where a system is partially upgraded).
In other words: If other libraries use your library, especially
unrelated libraries and on a large scale, you definitely want symbol
versioning or you want to be sure your ABI will never ever change.
Because usually the problem will be too ugly to even have to
cope with it 'only' every 10-20 years.
[1] in some easy cases RTLD_DEEPBIND might help, but I'd not bet on it.
Reply to: