Raphael Hertzog <hert...@debian.org> writes: > On Wed, 25 Jan 2012, Russ Allbery wrote:
>> 4. Once I had a symbols file that resulted in a successful build and that >> I could have uploaded, I started thinking about how I was going to >> maintain it. With a C program, I would change the symbols file >> versions when the underlying function implementation changes in a way >> that may not offer eqiuvalence, similar to bumping shlibs. I realized >> that I was going to have no idea when that happened, and the only way >> that I would maintain the symbols file would be to either trust >> upstream to maintain ABI equivalence and therefore only change the >> symbols file when upstream changes the SONAME, or not trust upstream to >> maintain ABI equivalence and therefore change all the versions with >> each new upstream release. That gives me exactly the same semantics as >> a shlibs file, so what's the point in having a symbols file? > The main benefit of the symbols file is that new symbols (API extension) > are listed with the version where they have been introduced. So that > seriously reduces the number of packages which would be affected by the > equivalent shlibs bump. My impression is that it's more difficult (not impossible, but more difficult) to maintain a C++ library in that fashion the way that one would maintain a C library, where one adds new symbols without requiring an SONAME change. Certainly, with the three C++ libraries that I maintain, upstream has a policy of not even attempting to do this. Bug fixes are made in an ABI-compatible way and should not, as I understand it, involve anything that would change the symbols file, and all other releases change the SONAME. I certainly believe there are carefully-maintained C++ libraries that are more conservative and that go to the required effort to make this work properly, and KDE is probably an excellent example of a large C++ project with enough C++ experts involved to do this properly. But I'm wondering how many packages we really have like that. By all means, if the library makes that possible, maintain symbols! But the library I looked at is fairly typical, I think, in that the maintainers are not deeply attuned to maintaining consistency of the export list in anything other than patch releases. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwf2x4uu....@windlord.stanford.edu
