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 _______________________________________________ pkg-multimedia-maintainers mailing list email@example.com http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers