[SCM] ecasound/master: update *.symbols files for the libraries

[Alessandro Ghedini]

On Thu, Mar 24, 2011 at 06:56:02AM +0100, Reinhard Tartler wrote:
> On Wed, Mar 23, 2011 at 22:59:22 (CET), Alessandro Ghedini wrote:
> 
> > On Wed, Mar 23, 2011 at 10:24:22PM +0100, Reinhard Tartler wrote:
> >> On Wed, Mar 23, 2011 at 21:55:14 (CET), ghedo-guest at users.alioth.debian.org wrote:
> >> 
> >> > The following commit has been merged in the master branch:
> >> > commit c13b7176fe7823bead9078961696295f94ff26e7
> >> > Author: Alessandro Ghedini <al3xbio at gmail.com>
> >> > Date:   Wed Mar 23 20:55:45 2011 +0100
> >> >
> >> >     update *.symbols files for the libraries
> >> >
> >> > diff --git a/debian/libecasound22.symbols b/debian/libecasound22.symbols
> >> > index d7af24a..5605429 100644
> >> > --- a/debian/libecasound22.symbols
> >> > +++ b/debian/libecasound22.symbols
> >> > @@ -65,6 +65,7 @@ libecasound.so.22 libecasound22 #MINVER#
> >> >   _ZN10ECA_LOGGER8lock_repE at Base 2.7.2
> >> >   _ZN10ECA_OBJECTD0Ev at Base 2.7.2
> >> >   _ZN10ECA_OBJECTD1Ev at Base 2.7.2
> >> > + _ZN10ECA_OBJECTD2Ev at Base 2.7.2
> >>
> >> Can you actually read this mangled mess of symbols?
> >>
> >>
> >> I still think .symbols file are largely practically useless for C++ libraries...
> >
> > AFAIK they are not meant to be read by humans, but they can be used by dpkg
> > for generating more accurate library dependencies.
> 
> They are supposed to be actively maintained by the package maintainer,
> so no, AFAIUI they are supposed to be read by humans.

What the maintainer is supposed to do with those files is checking for
backwards-compatibility brekage and, if the case, bump the version for 
those "broken" symbols. Nothing that can't be done in few seconds using
tools such as grep (until dpkg-gensymbols will support this). 

Since thay are automatically generated, there's no much work needed to 
maintain these files.

> > Anyway, they can be demangled using c++filt(1), if needed.
> 
> And I'd say this is badly needed in this case at hand.

I don't get this, what's wrong with doing:

   $ c++filt < debian/package.symbols | less

> > Also, there is the no-symbols-control-file lintian tag. It's just whishlist
> > severity, but IMHO it's nice to keep lintian as silent as possible :)
> 
> We had this argument before. We are not linitan pleasers, we want to
> please our users by creating technically correct and maintainable
> packages. Not every lintian warning makes sense, please take them with a
> grain of salt.

Isn't creating technically correct and maintainable packages the whole 
point of why the *.symbols files exist? They help in creating more accurate
dependencies between packages, and, I may be wrong, but, to me, they don't 
seem that "scary" or non-sense to need a removal.

If you insist I will of course remove them (we are a team, and we are
supposed to work togeter) but I fail at seeing the reason behind this.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'