Re: [luabind] Naming library with proper SONAME
Roberto C. Sánchez <roberto@connexer.com> writes:
> [My apologies in advance for the cross-posting.]
>
> On Tue, Mar 10, 2009 at 10:42:36AM +0100, Daniel Wallin wrote:
>> Roberto C. Sánchez wrote:
>> >>
>> > So, I've been trying to build the Debian package with the latest from
>> > the 0.8 branch on github. It seems like the SONAME thing is not
>> > completely resolved. I am seeing this after building:
>> >
>> > roberto@miami:~/src/luabind-upstream$ objdump -p ./bin/gcc-4.3.2/debug/libluabindd.so.0.8.0 |grep SONAME
>> > SONAME libluabindd.so.0.8.0
>>
>> Yes, that's the expected result, isn't it? The reasoning was that it's
>> too difficult to have ABI-compatibility, so we just use the complete
>> version number as the SONAME. "bjam install" will create the unversioned
>> symlink.
>>
>
> I am curious as to what people generally think of how the libluabind
> SONAME will be going forward. I know that certain packages (like
> libssl) have the complete version in the SONAME, but I can't imagine
> that this is a really good idea. Is this a showstopper for having
> libluabind in Debian, or just for a stable release? Is this
> discouraged, but otherwise permissible?
>
> I've looked in the Debian library packaging guide and it does not say
> one way or the other.
>
> I'd appreciate any insights and/or comments.
>
> Regards,
>
> -Roberto
The ABI needs to be compatible across all versions with the same
SONAME. If that means every upstream release gets a new SONAME than I
curse upstream for breaking their ABI all the time but the SONAME
would still be right. This should not really be a showstopper but
maintaining this won't be too easy. Every new upstream release will
need a binary package name change, NEW procesing and a library
transition. You better hope that the API doesn't change as often so
binNMUs can be done.
One would hope that at some point there will be a libluabindd 1.0.0
which would then have a more stable ABI.
MfG
Goswin
Reply to: