Comment 1 for bug 1275787

I try to update the symbols files regularly, but I admit that I don't do it often (enough) and others aren't particularly better. Looks like the version which ended up in ubuntu was particularly bad in this regard.

Well maintained c++ libraries are already hard to write a symbols file for as Russ summarized a while ago [0]. The policy helpfully says that it might not be a good idea for c++ at all. libapt adds to the pain as it isn't very good from a maintain-view: It isn't versioned, visibility isn't controlled, … Should I mention that a way to big part of the symbols file deals with different gcc versions creating different symbols? (which are of course symbols nobody cares about in the end). Failing the package build basically means we need to build apt at least two times with each upload: First with the first try and the second one with a symbols file we collected from all the failures. In the hope that we haven't forgotten one/hit another gcc version in the next try… a lot of work for the buildd, new ports and last but not least for an already understaffed apt team.

Personally, I hope we can be better in the future with maintaining it, but in the end the current state is at least a bit better than shlibs in so far as it is likely that we will forget to update this one as well which exposes users to bad things if they partial-upgrade/frontend forgets to enforce a higher version for the new symbol it uses.

Or in other words: Great, we have a volunteer taking care of maintaining it! SCNR ;)

[0] http://www.eyrie.org/~eagle/journal/2012-01/008.html