Recent changes in dpkg

[Reinhard Tartler]

On Do, Mai 27, 2010 at 10:02:31 (CEST), Jonas Smedegaard wrote:

> On Thu, May 27, 2010 at 02:13:16AM -0400, Felipe Sateler wrote:
>>On 24/05/10 05:05, Raphael Hertzog wrote:
>>>   * dpkg-gensymbols offers new ways to manage symbols files (matching C++
>>>     symbols by their demangled name, matching symbols with regular
>>>     expressions) thanks to Modestas Vainius.
>>
>>This should be useful for people using symbols files.
>
> Yep.  Already looked at it for JACK when that new dpkg was released.
>
> I see no real use for it there, until we have some knowledge on which
> symbols are actually the official ones across implementations of JACK.

Without knowing that, I don't think that using symbols file has much
benefit.

> For now I simply assume that if a symbol changes in a new release then
> it is sane (but the fact that it changes is then noticed and tracked
> through our git, if the assumption turns out to be wrong).  And I have
> lowered to only warn when most changes occur.

So you have effectively turned the dpkg-gensymbols mechanism to a source
of noise in form of warnings which are of no use since you don't know
what symbols are supposed to be public and what not.

> In other words, the symbols file is not used as the intended rigid
> safety net, but rather as a log to help understand problems *after* they
> occur.  This hopefully changes in the future by me or others gaining
> more knowledge in the symbols officially needed by JACK.

"understanding problems" after they occur? For this the service
snapshot.debian.org is a far better tool than symbol files.

BTW, this is exactly the reason why I had concerns at the time symbol
files were introduced. Currently it is an additional (mandatory?) tool
that increases the complexity of the package without direct (real)
benefit. For investigating and comparing exported symbols, I'd suggest
to use nm(1) or objectdump(1) with diff(1). In my eyes, dpkg-gensymbols
is just a tool that a) integrates these tools to the build process and
b) define an additional workflow for package upgrades.

As for the part "[having] some knowledge on which symbols are actually the
official ones across implementations of JACK" - that's actually crystal
clearly defined by the jack API documentation. We have already noticed
that there are tons of additional symbols being exported by jackd2 that
should better be hidden. Adi has spoken to upstream to hide them, but
AFAIUI that didn't lead to anything.


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4