Re: pkgkde-symbolshelper (Was: upgrade orfeotoolbox to 5.0)
On Tue, Sep 8, 2015 at 12:03 PM, Andreas Tille <andreas@an3as.eu> 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?
In general, I find the symbol-parts of debian documentation quite poor.
>
>> 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.
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.
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.
>
>> 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).
First of all, I appreciate the time you (Bas) take to answer this discussion.
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).
[1]https://github.com/libharu/libharu/commit/eebeb5dea6a66b2ab1ef40e6f09a4116766a6eaf
Reply to: