Re: Library help needed
Gerfried Fuchs <alfie@ist.org> writes:
> I am in the position to have to maintain a library package from a
> source where the upstream maintainer isn't familar with libtool and
> SONAME. Unfortunately me neither. I have read through the libtool-doc
> info pages about it and read the Library Packaging Guide, but still have
> no real clue how to tackle this. This is my first and only library
> package so I am not that familar with handling of these...
libtool versions are in the form x.y.z:
x = Current Interface
y = Binary Age
z = Interface Age
If your library is thus called `libfoo.so.x.y.z' (-version-info x:y:z),
the SONAME of the library is `libfoo.so.x'. This SONAME
objdump --private-headers libfoo.so.x.y.z | grep SONAME
SONAME libfoo.so.x
is identical in *binary compatible* versions of the library. When you
*break* binary compatibility (remove or change "interfaces"), you
increase x. When you *add* interfaces (without breaking binary
compatibility), you increase y. When you release a new version
without changing any interfaces, you increase z.
When x or y is changed, z is reset to zero.
When x is changed, y is also reset to zero.
Once you've got your head around the various changes you could make to
the interface (which includes symbols, headers and the behaviour of
functions etc.), it isn't all that difficult.
For some ideas about how to do this correctly, please see the
gimp-print source package (we version with -version-info). See
configure.in.in and src/main/Makefile.am. The Makefile has -release
versioning commented out (for use in unversioned development
releases). The library package is named libgimpprintx, where x is the
current interface.
> Here is how it goes: The package in question is metakit. The upstream
> maintainer doesn't add -version-info but lately uses -avoid-version
> (with previous source he hasn't used neither one, so the files were
> always .so.0.0.0). I may have made a mistake by adding a -version-info
> with a SOVERSION of 1:0:0 for my first upload, but that can't be taken
> back now.
I don't think you can sensibly use *any* soname versioning without the
cooperation of upstream (what about compatibility with other
distros). Programs linked against metakit on Debian should run with
other distributions' metakit libs...
I would use "-release $(VERSION)" versioning while upstream isn't
versioning properly, since this at least allows multiple versions to
co-exist (name the packages libfoo-$(VERSION)).
> I tried to talk to the upstream maintainer about the problem and he
> said he doesn't have a clue about libtool neither. So, what shall I do?
> Shall I increase the SOVERSION for Debian by myself, for afaict each
> upstream source _did_ change the interface. I am quite puzzled, and
> there passed some upstream versions by that I wasn't able to upload
> because of that yet. Fortunately the library isn't that intensively
> used, but I like to do it right[tm]. And especially I guess the problem
> to build the python bindings solved in the later upstream releases, so I
> guess it would be nice to have that, too.
I think the best solution is to educate upstream. Find other
libtool-using packages, and follow their example.
Proper versioning also requires discipline, not to change interfaces
in stable releases, making sure all changes are forwards-compatible
etc. In gimp-print, binary-compatibility is only broken in
development series. Doing this is sometimes a pain, but is necessary
for a stable interface.
> Ah yes. About splitting the package: It can produce usual c bindings,
> and tcl and python bindings. Shall I do a seperate package for each of
> them? And an additional -doc package? Or doesn't it hurt if I put them
> all into the same package (and the -doc things into the -dev package)?
> I like the idea of having specialized packages but on the other hand it
> always should be a matter of how small they would get. I dislike having
> much small sized packages rather than having some medium sized ones....
Personally, I would split them. In gimp-print, 10 binary packages are
produced from the same source (using debhelper). Feel free to use it
for ideas.
Regards,
Roger
--
Roger Leigh
"Liberty and Livelihood" - Support the Countryside Alliance
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848 available on public keyservers
Reply to: