Hi! It would be nice to have a private tag which would have the following semantics: * any symbol marked as such could not be used by any external package, it would produce a fatal error at dpkg-shlibdeps time. * such symbols could be used by binary packages produced from the same source package. * probably they should be non-optional by default, as there's the optional tag already, and there's no way to mark a symbol as non-optional anyway. So while this could alternatively be achieved by modifying upstream source, with one of the following methods: advanced or simple symbol versioning, symbol visibility or an export map; it might not be always desirable to diverge from upstream on this. So having support for this in Debian would allow package maintainers to disallow external dependencies on interfaces which are not supposed to be used. The biggest issue I see is how to transport that information from the symbols pattern file in the source to the binary package. thanks, guillem
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 Cheers,
Hello, 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.
Hi, Could be workable I guess. Except that the negation of 0 doesn't exist, so it forces you to have at least one extra dependency template. Are you at debconf this week? Cheers,
Hello, That might be an advantage to a certain degree, i.e. the default (0) template can never be private by design. However, if the maintainer aim is to always fail when a private symbol is referenced (either locally or externally), symbol dep_id could point to a non-existing template. Nope.