On Mon, 30 Mar 2009, Modestas Vainius wrote: > > I understand the need to mark symbols in > > multiple ways so that specific treatment/conversions are made but I'm not > > convinced that reusing the comment-based approach used for missing symbols > > is the best choice. > That's the way it was designed, I didn't invent this comment based approach. > You already treat those "comments" specially and that's even backwards > compatible with earlier versions of dpkg. If I invented my own ways, I would > risk patch rejection even more than I did now. Anyway, it is not important > what approach to marking symbols you choose as long as there is a way to mark > symbols as optional so dpkg-gensymbols would not be dumb and do not generate > long useless diff with readded optional symbols as it does now (and even bump > version number in addition, really nice!).
Those commented out symbols have been designed mainly to appear in the diff output and were not really intended to be integrated in the symbols files in the source (although it was expected that this would happen since mole-generated files do not strip them). > > And I might be interested in including that tool directly in dpkg too (or > > merging the features directly in dpkg-gensymbols if that's possible). > Believe me, you do not want to include that tool into dpkg-gensymbols / > SymbolFile.pm, maybe except arch-specific substitution part to eliminate > build-time dependency. Wildcards might do also as a replacement but there is > a > low level risk to be too prone to false positives. Anything else is out of > dpkg-gensymbols scope. As for dpkg, I'm not really excited about this, I > would > simply find myself too constrained due to the priority and importance of > dpkg. > dpkg should ship only low layer stuff and to aim to do "guessing" of any sort > as my tool does. You might be right but I'd like to be involved in that decision. Some parts might make sense in dpkg-dev directly. > > > PRIVATE - C++ template instantiations and other exported private symbols > > > (i.e. those which cannot be found in the headers). > > > > Are such symbols really never used by any binary (even in the same source > > package) ? > No, they are not. If template instantations are marked as explicit, they > become real external symbols. However there is no way to determine that from > the symbol file. I could only guess that if a template instantation is a > "weak" symbol, it's implicit. But deb-symbols do not store weakness. However, > in 99% of all cases template instantations are implicit (as in I have not > seen > one which isn't). I'm sorry, I'm not used to C++ internals. Can you explain me: - what's special in those symbols - why do you want to treat them differently - how do you want to treat them in general As I understand it, you want those symbols to be optional. Integrate them in symbols file of the library .deb but no complaint about their absence in the diff output during build. Don't you fear that with such a mechanism you'll gain a lot of cruft in your source symbols files that will largely go unnoticed as nothing complains about them and as they are silently dropped by dpkg-gensymbols ? > All are useful, they really are, but I'm only after the concept of private > symbols at the moment. Rather "optional symbols" in terms of functionality/behaviours that you want to associate with them. > > - java: (arch-specific?) symbol mangling > > - private-ignore: private symbols to ignore > > - private-include: private symbols to include > So you are proposing a syntax change here. Be prepared for convulted > private-ignore:c++:"Foo::Bar::Private::foobar()" if you go ahead with this. > The beauty of the current comment based syntax is that there is a place to > leave a comment (which I have to abuse at the moment). And comment based > approach lets you to stay compatible with earlier dpkg versions as a side > effect (don't you care about backwards compatibility of symbols files?). I care about backwards compatibility of symbols files inside .deb. I don't care about it in the source package since they can Build-Depend on the minimal dpkg-dev version needed. It's good to avoid too many disrupting changes when possible, but it's not good to abuse an existing interface. So I would rather like that we design some generic "symbol tagging" interface that can be used for your case and the other cases I mentionned (even if we don't implement it right now). So what would be a proper syntax for such a thing ? Using a prefix in the symbol name ? Adding a new field at the end of the line ? Do we want values to be associated to such tags or not ? optional:_znk6phonon22objectdescriptionmodelilns_21objectdescriptiontypee4ee10metaobjec...@base 4:4.3.1-1 ignore:_znk6phonon22objectdescriptionmodelilns_21objectdescriptiontypee4ee10metaobjec...@base 4:4.3.1-1 wildcard:*...@glibc_private 1.0 wildcard=c++:"Foo::Bar::Private::foobar()"@Base 1.0 optional:wildcard=c++:"Foo::Bar::Private::foobar()"@Base 1.0 It's a bit difficult to parse with the quoting though. Maybe we should have clearer delimiters for the prefix part. (optional:wildcard=c++)"Foo::Bar::Private::foobar()"@Base 1.0 Any opinion ? Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
