* Jay Berkenbilt <q...@debian.org> [111229 17:26]: > Julien Cristau <jcris...@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. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111229184029.ga2...@server.brlink.eu
