On 08-09-15 12:03, Andreas Tille wrote: > On Sun, Sep 06, 2015 at 01:41:28PM +0200, Sebastiaan Couwenberg wrote: >> >> Because C++ symbols are unstable, that does generate a bit more work, >> but easy to automate using pkgkde-symbolshelper. > > I have never heard about pkgkde-symbolshelper - may be it is not really > in the right place if it is of general interest even outside pkgkde?
The dependency of pkg-kde-tools are kept to a minimum because pkgkde-symbolshelper is useful outside of the KDE packaging team too. It hit my radar via the essays by Russ Allbery linked from https://wiki.debian.org/UsingSymbolsFiles I consider those essays must-reads for anyone considering whether or not to use symbols files for C++ projects. Russ made a very good argument why he decided to not use symbols files for C++ libraries after all. >> You just need to take >> care to update the symbols for other architectures after the buildds >> have built the package. > > Hmmm, that nuisance remains. :-( > > I admit I decided *personally* due to the fact that I usually deal with > leaf packages to not provide symbols files as long as it involves a lot > of manual work. This is very reasonable. I prefer to use symbols for C++ projects anyway despite its drawbacks because you never know when another project will start using it too. QGIS is a good example where symbols are not a big necessity, so I'm very understanding of upstream not adopting that change too. >> I've shared the recommended practices for shared library packages, how >> (or not) to incorporate that into the otb package is up to the >> maintainer, which I'm not. > > I do not want to contradict to your suggestions - I'm just curious how I > could more easily follow these recommended practices with less work it > would take me at my current state of knowledge. IMHO this topic is > important enough to spend some paragraph in the team policy and may > be we might copy this for other teams (or even better find a good way > to merge Blends team policies). Adding a section documenting best practices for shared library shlibs/symbols handling is a very good addition for the team policy indeed. I don't have much experience with shlibs files, so I don't consider myself the best candidate to document it's use, but I'll see what I can do when I get around to documenting this. I have a lot of things demanding my attention currently, so I can't promise to work on this in the short term. A team policy co-author or hit-and-run patch submitter is very welcome of course. :-) Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
