Re: Early adopters of symbol based dependencies needed
Raphael Hertzog <firstname.lastname@example.org> 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
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>