Re: Library version in name vs. so version
Roland Stigge <stigge@debian.org> writes:
> Hi,
>
> 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
>
> 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.
You can provide a libjasper-dev in each libjasper-1.XXX-dev and
you can add extra links for libjasper-1.so.1.0.0 or libjasper.so.1.0.0
and still keep the upstream name for the package.
But that would mean that every upstream update would get stuck in
queue/NEW for weeks, which is very inconvenient and extra work for
ftp-master. That's probably the deciding argument.
> -> 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.
Its also nice to have a libjasper-dev package (for libjasper-1 or
later libjasper-2) if source compatibility is likely.
> -> Besides, the -dev package includes include files in
> /usr/include/jasper/ (e.g. /usr/include/jasper/jasper.h) which causes
> the respective -dev packages of different upstream versions to conflict
> anyway. Would I have to provide a virtual package (e.g. libjasper-dev)
> to conflict with?
Having the -dev packages conflict is not a problem. They will only be
needed to compile packages which should always use the latest
version. Many libraries have conflicting -dev packages.
If you fear a future libjasper-2.XXX will be incompatible you could
suggest using /usr/include/jasper-1/ but depending on the amount of
software using it that might be difficult. And if incompatibility happens
libjaspter-2.XXX could use /usr/include/jasper-2 then without
libjasper1 having to change. Might be good to soften upstream up to
that idea so you don't have to convince him after he releases a future
libjasper-2.XXX.
> Thanks in advance!
>
> bye,
> Roland
>
> [1] http://www.ece.uvic.ca/~mdadams/jasper/
MfG
Goswin
Reply to: