"Bernhard R. Link" <brl...@debian.org> writes: > * Russ Allbery <r...@debian.org> [120127 22:30]:
>> This is probably the best summary of why a symbols file might be >> useful. It helps catch cases where ABI compatibility is not maintained >> without people being aware that this broke. > On the other hand a symbols file can also make situations worse if the > ABI changes and dpkg-gensymbols does not catch this case, as the > dependencies are less strict then. But this is true regardless; the same is true for shlibs. Either way, if there was an incompatible change that the Debian maintainer didn't catch that doesn't affect the exported symbols, you potentially lose. shlibs does make it easier to just always bump the dependency to require a matching upstream version, but you could in theory do the same thing with symbols. >> I think this is probably the summary of my previous message: a lot of >> those places don't seem as useful for C++ as for C, because ABI >> compatibility is a lot more complex (and in some ways a lot harder to >> maintain), so the equivalent of a shlibs bump is probably more >> frequently the right thing to do. > I think this argument can also mean that symbols files are more useful > for C++ than for C: For C there are many ways to break the ABI > incompatibly and compatibly without anything visible at symbol level. > As C++ is more likely to show differences at symbol level in this cases > the danger of cases where dpkg-symbols introduces wrong dependencies > might be lower with C++. It's true that C++ is much more likely to show symbol differences on at least some types of changes (such as changing the function signature, which with C++ is encoded in the symbol). However, C++ also introduces a significant number of new ways to break compatibility that just don't exist with C, some of which don't affect the symbols. But, more to the point for practical concerns, there appears to be a truly staggering amount of noise. What I'm seeing in these experiments is that trying to track symbols for C++ libraries, at least for ones that aren't using symbol export control, is that there are huge numbers of false positives and spurious differences from changes in platform and compiler, to the extent that one is awash in fixing symbol differences that don't represent any interesting property of the library but are just odd artifacts of how C++ is compiled. I think, given this experience, that symbols for C++ libraries, at least for the ones that I'm looking at, are a failed experiment, and I'm going to back out of all of these changes and go back to just using shlibs. That seems particularly indicated in this case, since upstream changes SONAMEs for these libraries regularly and hence it's very rare for it to be even possible to attempt running stable binaries with unstable libraries or vice versa. There has not yet been a case where stable and oldstable had the same SONAME for one of these libraries. That eliminates much of the advantage of symbols; the remaining advantage is detecting ABI breaks, but since upstream changes SONAME regularly, most of the damage from ABI breaks would be limited in this case anyway. Somewhat more controversially, so I'd like to get a debian-devel feeling on this, I think the Lintian info tag for a library using shlibs instead of symbols should be suppressed if the library is a C++ library (probably most easily detected by seeing if it depends on libstdc++). There *are* excellent tools from the KDE team available, but even with those tools, this turned into something I wasn't willing to deal with, and I'm a fairly experienced packager. I have a hard time imagining the average Debian packager is going to be equipped to deal with this properly, and for most C++ libraries just using shlibs and dh_makeshlibs -V to conservatively set the dependencies is probably the best tradeoff of usability against maintainer time. If packagers are willing to do more, more power to them! Some C++ libraries may be amenable to it. But a Lintian tag implies that packagers who are not doing this are doing something (minorly) wrong, and I don't think that's actually the case. -- 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/87k44bo169....@windlord.stanford.edu
