Re: pkgkde-symbolshelper (Was: upgrade orfeotoolbox to 5.0)
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 <[🔎] 55EC2668.1000201@xs4all.nl>:
"
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
Reply to: