Re: Using symbols files
On Tue, Jan 15, 2008 at 10:44:32AM +0000, Neil Williams wrote:
> On Tue, 2008-01-15 at 09:35 +0100, Stefano Zacchiroli wrote:
> > On Mon, Jan 14, 2008 at 06:56:18PM +0000, Neil Williams wrote:
> > > Quick summary: IMHO, symbols files are largely irrelevant if not
> > > supported upstream via versioned symbols.
> > Can you please argument this?
> (You omitted the rest of that paragraph which contained my reasoning for
> that statement)
> Symbols files need data from --version-script in order to calculate much
> more than a static list of symbols. i.e. generating symbols for a
> library that does not use versioned symbols will end up with a list that
> has no history. Each time you generate it, the list of symbols will be
> "new" when they are not.
This is only going to happen if you discard your existing symbols file
for each new upstream version of your library. If you're doing that
then obviously you're going to loose any information you already have.
Much simpler is to keep your symbols file, add new symbols (a diff will
be printed when you use the old file) and review for any unintended or
non-symbol changes.
> in 0.7.3 (or actually some might have changed but without versioned
> symbols you cannot tell).
Versioned symbols make no difference except possibly in the bootstrap
case. All versioned symbols do is let upstream change a symbol
incompatibly without breaking compatibility with exisiting users or
requiring a soname bump (effectively by rewriting symbols to have an
extra string at the end). From a dpkg symbol files point of view this
means that you've got packages with longer symbol names, more or less.
You still need to check that upstream haven't broken the ABI on existing
symbols unintentionally or enhanced their functionality in a way that is
compatible but still means that you want to bump the requirement in the
symbols file.
> Instead, the maintainer needs to work with upstream to convince them of
> the importance of a stable API/ABI over a series of releases,
> coordinated SONAME transitions and other issues around the versioning of
> the library. Otherwise, the maintainer will have quite enough to do with
> constant package name changes to keep up with the consequences of
> upstream not retaining a stable ABI. If the library changes API at every
> release, a symbols file won't help anyone because applications using the
> library will have to make a transition anyway. A symbols file is only
Right, as you say the problems here are nothing to do with symbols
files or symbol versioning. A poorly maintained library is going to
create trouble no matter what and a well maintained library should be
fine even if it does not use versioned symbols.
For example, the zlib library has never had a soname bump because
upstream are careful to only add new interfaces. It does have versioned
symbols now but they are very recent and don't achieve an enormous
amount yet since there are no symbols which have changed ABI. I'd be
surprised if that ever happened since upstream supports platforms which
do not support symbol versioning at all. Similarly, some proprietary
libraries I'm aware of do their own custom symbol versioning in the
symbol name in order to handle platforms without symbol versioning.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
Reply to: