Bug#620629: mathgl: NMU for these bugs

[Dimitrios Eftaxiopoulos]

Στις Τρι 21 Ιουν 2011 02:21:15 γράψατε:
> Hi Dimitrios,
> 
> On Sat, Jun 18, 2011 at 11:41:02AM +0300, Dimitrios Eftaxiopoulos wrote:
> > Thank you for your patch regarding symbol failures of mathgl. In a recent
> > communication with Sylvestre Ledru we decided to to drop symbol files due
> > to many FTBFS and due to the much time consuming effort of editing the
> > symbols files after each FTBFS.  This is what I was planning to do when I
> > will build and upload the new version 1.11.2.  If you think that it is
> > worth keeping the symbols files and we can avoid multiple FTBFS with your
> > changes, I don't mind keeping them.
> 
> It is my opinion that every library package in the archive should use
> symbol files eventually.  The two main benefits of symbol files are:
> 
>  - reverse-dependencies that only use older symbols will have a weaker
>    versioned dependency on the library, making upgrades easier
>  - accidental upstream library ABI changes won't go unnoticed in the
>    package, being caught by the ABI checker (which is what's been giving
>    problems here so far).
> 
> The build failures have been almost entirely due to symbols that are not
> part of the library ABI, but are g++ implementation details instead.  These
> symbols should be correctly marked 'optional', because /for each
> architecture/, they will come and go with changes to the toolchain.  I
> think the reason you were having so many problems nailing down the symbol
> files is because you were racing various toolchain changes on the
> different architectures. :)
> 
> My previous NMU did turn up a handful more symbols which also need to be
> marked 'optional', as I said it might.  But after that, mathgl should build
> on all architectures and the symbols files should be mostly stable.  There
> is the possibility of future toolchain changes causing further changes to
> which destructors are exported in the symbol table, but those can again be
> handled by marking the destructor symbols optional.  (I haven't tried to do
> this yet because there are a bunch of destructors for foreign classes whose
> destructors are exported, and I don't completely understand why these are
> exported on one architecture vs. another.  But it's *probably* safe for you
> to mark all foreign destructors as optional.)
> 
> Anyway, attached are the NMU patches from a second NMU (both an incremental
> patch versus the previous NMU, and a full diff for the two NMUs), which I
> will upload shortly.  With this, mathgl will build on all official
> architectures, and should also build on all the debian-ports architectures
> (though I can't be certain of this, because no ports architecture has tried
> to build the package since my previous upload).
> 
> If you are still considering dropping the symbols files, please file a bug
> report against dpkg-dev first.  If it's at all possible to do so,
> dpkg-gensymbols should be handling these kinds of optional symbols
> centrally, not requiring maintainers to manually tag them all as optional.
> I'd hate to see us lose symbols files from the archive because a maintainer
> found them too difficult to use.
> 
> Thanks,

Hello Steve,
I had overlooked the external and C++ implementation related symbols that are 
not part of the library ABI and can be marked 'optional'. Definitely chasing 
them was time consuming. 

Thanks for your help, clarifications and nmu's which help me to continue the 
symbol usage within mathgl.

Bests
Dimitris