[Top][All Lists]

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

Re: Shishi/GSS no-symbols-control-file lintian warning

From: Simon Josefsson
Subject: Re: Shishi/GSS no-symbols-control-file lintian warning
Date: Thu, 26 Feb 2009 01:11:10 +0100
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)

Russ Allbery <address@hidden> writes:

> Hi Simon,
> I'm sorry it took me so long to reply to this message.  It got stuck in my
> backlog and got put off due to a very chaotic last quarter of last year.

Hi Russ.  Don't worry, and thanks for guiding me through this.  I
recently started helping debian packaging of libidn and gnutls too, so
debian symbol versioning will probably be useful to understand.

>> However, I haven't found a simple to understand explanation of best
>> practices on how to modify this file.  deb-symbols man page doesn't help
>> me, nor does <>.
> is the new URL that explains how
> to implement this.  I'm going to add that as an additional reference in
> Lintian for the no-symbols-control-file tag, since it's somewhat easier to
> follow than the dpkg-gensymbols(1) man page and includes a link to mole.

Indeed, I think that link is more useful for maintainers.

>> * Do I have to modify the file considering that debian unstable contains
>>   0.0.23 with the same ABI?
> You should ideally adjust the 0.0.24 versions to instead be the first
> version at which those symbols existed with their current ABI.  It doesn't
> matter a tremendous amount the first time around, though; what matters
> most is how the file is maintained in the future.

The files I downloaded from mole seem to take care of this; it contained
earlier version numbers for most symbols and newer version numbers on
some more recent symbols.

>> * Generally, should I bother with a *.symbols file at all?  I get a
>>   feeling from the wiki page that people haven't really decided that
>>   this is the way to go, and I haven't found many debian packages that
>>   use a *.symbols file either.
> The utility of the symbols file is directly proportional to how many
> packages depend on that shared library.  I plan on introducing them for
> every package I maintain (with the the exception of C++ libraries) just
> because they're fairly easy to maintain if you already know how the ABI is
> changing.  But they're particularly valuable for glibc, libpng, and
> similar libraries that are very widely linked against.  I think most of
> the focus and attention so far has been on those libraries rather than on
> every library package in Debian.
> I expect symbols files will get gradually more attention as time goes on.
> (For example, they're not in Debian Policy yet, and I want to add them.)

Ok.  The advantage for Shishi is probably somewhat questionable right
now, then, but I prefer for my packages to be neat and to implement the
best current practices, so I'll work to make this happen.

I'm getting close to upload 0.0.38 packages...  should I upload to
experimental so you can review the package more easily, or can you
review through the CVS repository and I can upload to unstable?  Unless
you want to do the upload, of course.  Alas, the CVS repository doesn't
seem to have any tags for the last upload, but you could compare to the
version in lenny.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]