On 08-09-15 17:27, Johan Van de Wauw wrote: > Unless I'm understanding it wrong, I don't see much value in adding > symbol files for packages like OTB or saga which have the release > number in their soname. > I think it might have been useful during eg the libstdc++ transition, > but for normal updates for a new upstream release the symbol files are > useless (correct?) because we have new libraries anyway.
Thanks to the unstable C++ ABI for GDAL I've become very skeptical of the ABI compatibility between patch versions for C++ libraries. We only have the complex split C/C++ symbols for GDAL (now with virtual ABI package too) because every patch version breaks the C++ ABI. Can you be sure that all future OTB 5.0.x releases will remain ABI compatible? I surely hope so, everyone should be spared the complexity we're forced to deal with for GDAL. Only when there are no reverse dependencies of the libraries outside the project, and that eventually happening can pretty much be ruled out, should you not use symbols nor shlibs for library packages. > Apart from that, note that symbol files may miss some actual changes. > An example from libharu: [1]. Suppose this is the only change, symbols > would not change, but any program compiled against the old version and > using HPDF_PAGE_LAYOUT_EOF would actually be broken. libharu being a C project is not a very good example in the context of the OTB discussion and the complexity of dealing with its C++ libraries. symbols files are not a replacement for proper library versioning by the upstream developers. Your example demonstrates why such an ABI breaking change needs to be reflected with a SONAME bump. Having the library packages match the SONAME makes sure that the dependencies on the library package change when the ABI compatibility does. > We should take care that we don't make packaging too hard if we want > to engage more team members. With the current documentation building > these c++ symbols is hard, and the added value for the end-users > small. I don't think it should be reason not to upload (I'm not > talking about packages with a lot of reverse dependencies). Shared libraries are placed in the Advanced Packaging section of the Debian New Maintainers' Guide for a reason. Handling shared libraries properly requires more work an understanding than packaging a simple single binary. It used to be common advice to not start with library packaging if you're new to Debian packaging, that's still good advice. Don't immediate jump into the deep end unless you can quickly learn to swim. Or you have people on side helping you not to drown. :-) In the context of this discussion it's important to emphasis what the Debian Policy says about symbols for C++ libraries, because symbols files are not the only option, shlibs files are perfectly fine too: " symbols files are therefore recommended for most shared library packages since they provide more accurate dependencies. For most C libraries, the additional detail required by symbols files is not too difficult to maintain. However, maintaining exhaustive symbols information for a C++ library can be quite onerous, so shlibs files may be more appropriate for most C++ libraries. [...] " https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-depends Following the piuparts tagline: "Policy is your friend. Trust the Policy. Love the Policy. Obey the Policy.", my stance on C++ symbols is summarized in <[email protected]>: " If you don't want to deal with C++ symbols, you'll have to manually maintain shlibs files. Hence the preference to symbols files that have tooling for updates. " Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
