[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Early adopters of symbol based dependencies needed



Raphael Hertzog <hertzog@debian.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
   head yet.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Reply to: