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)
Here is the full paragraph:
> Quick summary: IMHO, symbols files are largely irrelevant if not
> supported upstream via versioned symbols. Versioned symbols are
> largely useless if the upstream maintenance is generally poor or has a
> particularly poor understanding of libtool versioning. Versioned
> symbols involve continuous maintenance upstream every time a symbol is
> modified (e.g. new functions added) but have no effect on changes
> within functions that do not modify the function prototype itself.
> Symbols files involve regular maintenance by the Debian maintainer.
I've omitted it because I was asking about the first claim of that
paragraph which doesn't seem to me backed by its remainder part.
Rather, AFAIU the remainder part uses the first sentence as a starting
point. But anyhow, let's see ...
> 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
Well, no, I disagree: it's simply that you can't extract the history
from a single compilation of upstream sources. You still can maintain
the history Debian-side and use the symbols available on mole (i.e.
those coming from the last stable release as a starting point). Note
that I'm not claiming that this is handy or smart, but it is not true
that you are necessarily without history.
> symbols uses the same version for all symbols - but each time you create
> a new release you generate a new symbols file (because no versioned
> symbols exist) and all the versions increment to the current release as
> if they were all new.
Again, no, you can use the diff returned by dpkg-gensymbols and apply it
to the old symbol files de facto extending the history available on
Debian side. After all the whole mechanism is to have a history for
Debian purpose and is Debian-version centric.
> e.g.
> libqof.so.1 libqof1 #MINVER#
> LIBQOF_0.7.2@LIBQOF_0.7.2 0.7.2
>
> at v0.7.3 becomes
> libqof.so.1 libqof1 #MINVER#
> LIBQOF_0.7.3@LIBQOF_0.7.3 0.7.3
>
> That's wrong because those symbols existed in 0.7.2 and have not changed
> in 0.7.3 (or actually some might have changed but without versioned
> symbols you cannot tell).
But using the diff you won't have bumped the version number in the
symbol file, as it has already existed.
So, summarizing, ok: I agree that if upstream has versioned symbols you
can bootstrap from a more detailed state (but the fact that this is
needed for Debian is not necessarily true: to me it seems that it would
just make backport easier) and you will be able to recreate the history
from scratch when you want, but this is far from asserting that symbol
files are useless otherwise.
> The most important consideration is that if upstream do not know or care
> about versioned symbols, the library API is likely to be poorly
> maintained and the symbols file would be useless anyway. i.e. if
> upstream do not know or care about versioned symbols, upstream is likely
> to have a poor understanding of libtool versioning and poor API
> maintenance in general and the work involved in correcting things in the
> Debian package is probably not worthwhile.
Speculation :) YMMV. And at least we can FTBFS if changes go unnoticed
by the maintainer simply looking a upstream changelog or making quick
tests.
Cheers.
--
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/
(15:56:48) Zack: e la demo dema ? /\ All one has to do is hit the
(15:57:15) Bac: no, la demo scema \/ right keys at the right time
Attachment:
signature.asc
Description: Digital signature