Hello, On 2009 m. March 30 d., Monday 16:56:35 Raphael Hertzog wrote: > I'm reluctant to include any code change without seeing the final tool > that requires those changes. Well, I was afraid to get answer like this. It seems I have a bad karma these days.
> 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!). > 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. > Can you be more specific ? I think that could be useful. But I can't think of the use case now though. I would not feel bad if you omitted this part. Just please preserve what is written as #(MISSING|DEPRECATED|PRIVATE) in the dump(), that would be a step forward. > > 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). > For easier handling of C++/java symbols it might be interesting to follow > the logic of wildcard symbols that would be converted on the fly i.e. the > debian/pkg.symbols could contain: > c++:"std::basic_string<wchar_t, std::char_traits<wchar_t>, > std::allocator<wchar_t> >::find_last_of(std::basic_string<wchar_t, > std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, unsigned int) > const" 1.3 I would applaud such feature, but it is out of scope for this bug report. Wildcards can be useful to rule out symbols from the specific namespace, say Foo::Bar::Private*. But then we are back to this bug report again. There should be a way to mark them as PRIVATE. You mix a few features here like c++filt support, wildcards in the symbol names and concept of private symbols. All are useful, they really are, but I'm only after the concept of private symbols at the moment. > And when the symbol "_ZNKSbIwSt11char_traitsIwESaIwEE12find_last_ofERKS2_j" > is encountered, c++filt is called and we can make it match with the source > definition above. We could ensure that each unmangled definition gets used > at least once otherwise we make it appear as missing in the output. I'm not arguing whether this is useful or not (yes, it is useful as my tool is already doing this). But please do not make this bug report about my tool otherwise this simple request will drag for months without results. > We could possibly integrate a generic prefix scheme to be able to deal > with all case that could be of interest: > - c++: arch-specific symbol mangling > - 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?). #PRIVATE: TEMPLINST# _Zsymbolname 0.1 currently I have to do the following to be able to recognize a private symbol. #DEPRECATED: PRIVATE: TEMPLINST# _Zsymbolname 0.1 P.S. Having said all this, the tool is already written (it is in the pkg-kde- tools package, called pkgkde-symbolshelper) and is already being used with some success (e.g. phonon, soprano, strigi, kde4libs (libplasma3 only), taglib). Just look at the end of the build logs of these packages and see how long, ugly and useless (in the way, that real problems are hidden) dpkg- gensymbols diff can get. This bug report is only to solve this, I successfully workarounded other limitations. Don't get me wrong, your ideas are ok, but am I really requesting too much for a short term solution? -- Modestas Vainius <modes...@vainius.eu>
signature.asc
Description: This is a digitally signed message part.
