[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
ELF.
> The major version number of a library should not be increased unless the
> change would break binaries built against the old library.
Agreed.
>> 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>
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?
Thanks,
Simon
- Debian upload of 0.0.27?, Simon Josefsson, 2006/09/15
- Re: Debian upload of 0.0.27?, Russ Allbery, 2006/09/15
- Re: Debian upload of 0.0.27?, Simon Josefsson, 2006/09/18
- Re: Debian upload of 0.0.27?, Russ Allbery, 2006/09/18
- Re: Debian upload of 0.0.27?, Simon Josefsson, 2006/09/19
- Re: Debian upload of 0.0.27?, Russ Allbery, 2006/09/19
- Re: Debian upload of 0.0.27?,
Simon Josefsson <=
- Re: Debian upload of 0.0.27?, Russ Allbery, 2006/09/23
- Re: Debian upload of 0.0.27?, Simon Josefsson, 2006/09/25
- Re: Debian upload of 0.0.27?, Russ Allbery, 2006/09/25
- Re: Debian upload of 0.0.27?, Simon Josefsson, 2006/09/29
- Re: Debian upload of 0.0.27?, Russ Allbery, 2006/09/29