Steve Langasek wrote:
> > Finally, why not add the symbol informations to the shlibs file (that
> > can be done in a backwards compatible way) instead of creating yet
> > another control file ?
>
> I'd rather we didn't, even if it doesn't break anything it still abuses the
> shlibs file format as defined in policy. And what happens if you
> (improbably) have an overlap between a library name and a symbol name?
Note that policy doesn't fully document[1] the current shlibs format,
which is:
[package-type:] library-name soname-version-number dependencies...
It seems that this could be extended to include symbol information:
[package-type:] library-name soname-version-number dependencies...
[symbol dependencies...]
[...]
Like the package-type extension, this extra information will be
transparently ignored by old versions of dpkg-shlibdeps. Besides being
slightly more compact[2], it also has benefit of allowing inclusion of
differing symbol information for udebs, if it ever becomes useful to do
so.
--
see shy jo
[1] #363133
[2] Would it be worthwhile to support multiple symbols on one line to
save even more space?
symbol [symbol...] dependencies...
Attachment:
signature.asc
Description: Digital signature