Re: pkgkde-symbolshelper (Was: upgrade orfeotoolbox to 5.0)
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
Reply to: