help-shishi
[Top][All Lists]
Advanced

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

Re: Debian upload of 0.0.27?


From: Russ Allbery
Subject: Re: Debian upload of 0.0.27?
Date: Tue, 19 Sep 2006 15:19:21 -0700
User-agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux)

Simon Josefsson <address@hidden> writes:

> Ah, I see.  I've seen that in several other packages.  I actually
> experimented with that too, but I tried to avoid the hard coded version
> and put some variant of ${Source-Version} or ${source:Version} but it
> didn't work.  Is there no way to do this, or did I do something wrong?

Those substitutions only work in debian/control (and only in the binary
package sections of debian/control, for the record).

You can, however, do something like:

    version := $(shell dpkg-parsechangelog | grep ^Version: \
                 | cut -d' ' -f2 | cut -d- -f1)

and then use $(version) in the substitutions.  Ugly, but it should work.

> If I bump the major symbol version every time I add a new symbol, which
> is what I believe the libtool manual recommends, I think it would work.

libtool doesn't actually recommend this.  The libtool documentation is
just horribly confusing (and I was confused by this part of it for quite
some time).  What libtool recommends is that you bump the first number in
the string passed to -version-info.  This is *not* the same thing as the
shared library version expressed on disk; libtool derives that version
from the -version-info string using some additional semantics.  You'll
discover (at least this is what I've observed in the past) that if you
bump the first number and increment the last number, as the libtool
documentation recommends, libtool *won't* actually increase the major
symbol version.

I wish that libtool hadn't invented its own separate versioning system
that doesn't match the ELF version information in the library, since I
think this confuses a lot of people.

The major version number of a library should not be increased unless the
change would break binaries built against the old library.

> Ah, that was the piece of information I was looking for in the policy
> manual.  It described SONAME and similar, but never discussed when it
> must be incremented and when it must not be incremented.  I may have
> missed something, though.

The Debian library packaging guide is somewhat more helpful here.  See:

<http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html>

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>




reply via email to

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