shlibs vs symbols?
On Tue, 05 Feb 2008, Paul Wise wrote:
> I was reviewing a library package RFS (libthai) and I noticed that the
> shlibs pointed at version X and all the symbols in the symbols file
> pointed at an earlier version. Here I assume that the shlibs should be
> changed to point to the earlier version?
No. It's quite common for maintainers to use dh_makeshlibs -V and always
generate a dependency on the latest upstream version. The dependency is
too strong most of the times, but's it's not a bug. Furthermore, if they
have a symbols file, it's even less important since the information from
symbols files take precedence.
> libaa1: shlibs 1.2, symbols all 1.4p5
Given that 1.4p5 is the version in oldstable too, this doesn't change
> libgpewidget1: shlibs no version, symbols max 0.115 min 0.88
> libtheora0: shlibs no version, symbols min 0.0.0.alpha7.dfsg-1.1 max 1.0~beta1-1
Here one could argue that the shlibs file is broken since >= 0.115 ought
to be used in the shlibs (since some symbols have been introduced by
0.115). Same for libtheora.
> libgtkspell0: shlibs 2.0.2, symbols all 2.0.10
2.0.10 is in oldtsbale => non-issue
> libogg0: shlibs 1.1.3, symbols max 1.1.0, 2 removed symbols
Removed symbols ought to be stripped by the maintainers in the symbols
files that they provide...
> libqof-backend-qsf0: shlibs no version, symbols all 0.7.3, changelog goes way back
> libqof1: shlibs no version, symbols all 0.7.2, changelog goes way back
Strange, stable has 0.7.1... and lack of version in shlibs is probably a
bug, but one that can't be triggered except by building on etch with a
dpkg-dev that doesn't support symbols files yet.
> Am I correct in thinking that either the shlibs or the symbols for some
> of these are wrong?
In theory yes, in practice it's useless to require both to be in sync.
What's important is that symbols files match reality.
And symbols file can have too high versions, it doesn't hurt much when the
given version is already in oldstable/stable.
> If so, I guess I should file wishlist bugs for lintian tests for some of
> these situations? Like shlibs too cautious, shlibs too relaxed, symbols
> not produced from enough versions.
IMO this is a bad idea. There's no requirement that symbols files include
history up to oldstable... and like I said, shlibs are no more used when
you have symbols files, so a too-strong shlibs is ok given that it's only
used in the rare cases when an old dpkg-dev is used (backports).
> Also, does mole use packages from oldstable or the morgue or
> snapshot.d.n to create the symbols file it distributes?
Le best-seller français mis à jour pour Debian Etch :
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com