Russ Allbery <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> 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
_______________________________________________
Help-shishi mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-shishi
