[Pkg-crosswire-devel] API/ABI compatibility, and choice of SONAME for libsword

[Daniel Glassey]

On Sat, Jan 24, 2009 at 6:31 AM, Jonathan Marsden <jmarsden at fastmail.fm> wrote:
> Matthew Talbert wrote:
>
>> Newbie sort of question here. According to the page referenced,
>> couldn't the package name be libsword-1.5.11 and SONAME
>> libsword-1.5.11.so ?
>
> Well, sort of yes (you'd need the number in the name, before the dash),
> but I think then it is very obvious that libsword falls into the
> category of being unstable, in 5.2.2 of the guide:
>
> "The upstream authors have the liberty of choosing two major methods for
> versioning using libtool. -version-info, and -release. -release is used
> for unstable libraries that change ABI on every new release. However,
> such unstable library package usually don't belong in Debian, because it
> will require a rebuild in every dependent package against the new
> library package."

which is this case is, practically speaking, irrelevant. All the
packages to be rebuilt are to be maintained within this group. It does
mean that the new sword lib can't be uploaded to non-experimental
until all the frontends can build on it, then sword gets uploaded and
autobuilt, then the frontends get uploaded. That is the way it has
been so far.

> I suspect that submitting a library package that did the
> "libsword1.5.11" or "libsword1511" type of thing could just lead to it
> being rejected for this reason, and so it wouldn't get into Debian at
> all.  The standards for Debian packaging have evolved slowly over more
> than a decade; I think it's best not to fight them.  We need Debian more
> than Debian needs us!
>
> I did find *six* library packages with an obvious three-part x.y.z style
> version number in their names on my desktop (Ubuntu 8.10 amd86) here,
> -- but I think that is the exception that proves the rule, or something;
>  six out of over 700 is less than one percent.

What about things like all the gnome libs e.g. libpango-1.0.so
That looks similar to me to libsword-1.5.11.so though I do agree that
I can't see many others that are x.y.z.so

>> Just going off memory, I think libsword breaks ABI and perhaps API
>> compatibility on minor releases (eg, 1.5.9, 1.5.10, 1.5.11 all being
>> incompatible).
>
> Which seems to qualify it as being an unstable library, not really
> suitable for inclusion in Debian... we'd better hope no-one calls us out
> on that.

I can't see it being a problem as it has been ok the last 8 years
uploading new libswordx packages. The worst I can see happening is
that the name is rejected and we have to go back to libsword7

>> So it would make sense to me that the package name
>> could be libsword-1.5.11 so it could co-exist with libsword-1.5.9.
>> Please let me know if I'm misunderstanding.
>
> Note that the current binary package name portion is not libsword, but
> is libsword6 (libsword6-1.5.9-8.1ubuntu1 in Ubuntu Intrepid, for
> example!), the next one would be libsword7.  Number before the dash, so
> that it is part of the name.  Different package names, so they can coexist.

I have no objection to the package name be libsword-1.5.11 and SONAME
being libsword-1.5.11.so as long as there is no way it can break upgrades.

As is says in the Debian Library Packaging guide: 'It is quite
important that Debian does not lose binary compatibility with other
distributions, so changing the SONAME specifically for Debian is
generally a bad idea. Discuss and convince the upstream to use a saner
method for determining the SONAMEs.'

I hadn't thought of that before, so yes, we do need agreement with
what works upstream and what works within Debian/Ubuntu.

Regards,
Daniel