[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Library version in name vs. so version



On Sun, Jun 20, 2004 at 04:15:34PM +0200, Goswin von Brederlow wrote:
> Roland Stigge <stigge@debian.org> writes:
> > adopting the jasper JPEG 2000 library[1] in Debian, I'm struggling with
> > the upstream convention of incorporating the package version into the
> > library name. I.e., the shared library is created as
> >
> > /usr/lib/libjasper-1.701.so.1.0.0

Tell upstream that their versioning scheme does not make sense. They
should use either libtool's -release, or -version-info scheme, but not
both of them as they do now. -version-info is the default for a mature
library where upstream keeps a close eye on compatibility issues.
-release is used in experimental or development stages where upstream
does not want to care about compatibility. The latter case also raises
doubt whether the library is already suitable for packaging at all.

> > for jasper-1.701.0. Following Policy chapter 8, the respective binary
> > package names would be:
> >
> > libjasper-1.701-1
> > libjasper-1.701-dev
> >
> > This implies that on every upstream update, the binary package name
> > would need to be changed.

... and all dependent packages need to be rebuilt (unless you also
change the name of the source package). One more reason to stay away
from packaging -release versioned libraries.

> > -> Is this the way to go or should I try to convince upstream to change
> > the policy and name the shared object e.g. /usr/lib/libjasper.so.1.0.0
> > utilizing the soversion on updates?
> 
> libjasper-1 is probably a good compromise. Any change in the ABI and
> soname will hopefully result in a libjasper-2.XXX upstream version
> while different libjasper-1.XXX should be ompatible (I thope) and then
> you can easily have libjasper-1 and libjasper-2 in debian for the
> transition.

No, do not compromise on package names. Get versioning sanitized
upstream, then choose the proper package name according to policy.
Trying to solve this on a packaging level will likely get the Debian lib
(and the apps linked with it) incompatible with the rest of the world. 

See also http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
for information on library packaging.

Regards,

Daniel.



Reply to: