[Top][All Lists]

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

Re: Debian upload of 0.0.27?

From: Simon Josefsson
Subject: Re: Debian upload of 0.0.27?
Date: Wed, 20 Sep 2006 10:42:25 +0200
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux)

Russ Allbery <address@hidden> writes:

> 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.

Great, I should have thought of something like that.

>> 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.

Ah, yes.

> 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.

I tend to agree, although as a defense, perhaps libtool came before

> 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:
> <>

Ah, I was looking for something like that.  Thanks for the pointer.

Ok, I now believe debian-shishi is ready for upload, for 0.0.27.  It
is lintian clean.  Could you take a look?


reply via email to

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