Hello, On pirmadienis 13 Birželis 2011 11:03:19 Raphael Hertzog wrote:
> Since private symbols are not to be used outside of the source package, > we can just invent a special value to use in the associated minimal > version field. > symbol@Base *private* > > If that's not ok, then the easiest is to add a supplementary (optional) > field/column on each symbol line. But it requires to make the dependency > number explicit in the cases where it was omitted. > symbol@Base 1.2-3 0 private What do you think about using a negative dependency template id in order to trigger dpkg-shlibdeps failure? In my opinion, it's still useful (for reference purposes) to have version information even for private symbols. Negative dependency template would be treated like its abs() value except dpkg-shlibdeps would fail if the symbol file was from the external package. However, yet I haven't tested how dpkg-gensymbols from squeeze handles negative IDs. Hopefully, it fails in some (weird) way :) P.S. I plan to work on #615940, #630342 and #630344 in the next days/weeks/month. Maybe I will even propose something acceptable for #533916 in the process. -- Modestas Vainius <[email protected]>
signature.asc
Description: This is a digitally signed message part.
