Raphael Hertzog <[EMAIL PROTECTED]> writes: > since the upload of dpkg 1.14.8 to unstable, it's now possible for > library packages to generate "symbols" control files that will be used > by other packages to get more accurate (and less strict) dependencies.
> As this is a far reaching change, I'd like some skilled maintainers to > try it out "for real" and help me flesh out some generic guidelines so > that when we start using it on more packages, we do it right from the > first time. A couple of early points of feedback, which I'll send here since I think they'd benefit from broader discussion: * The seed symbols files include the full Debian package version for when the symbol was first available. For example, for libremctl1, all of the symbols are marked as first available in 2.10-1. This causes a problem for backports. A backport of 2.10-1 would provide all the same symbols, but would have a version of 2.10-1~bpo40+1 or something similar. This would be less than the version advertised by the symbols file, which means that the backport wouldn't satisfy the regular package dependency even though it would work. This will mean that symbols files will have to be adjusted when building backported packages, unless I miss some subtlety. I always use dependencies like >= 2.10 in shlibs files rather than the more specific 2.10-1 because of this problem. I'm not sure if that's the right general solution, but people who start from the seed files should at least consider removing the Debian revision in cases like this to make backporting easier. * The new warnings from the dpkg-* tools warn about any binary Perl module because all binary Perl modules use symbols from Perl itself but traditionally aren't linked directly against libperl. (There was some reason for this that I don't recall off-hand.) Should these warnings just be ignored? Suppressed in some way? Should binary Perl modules link against libperl? I haven't worked through the implications in my head yet. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
