packaging jack...

[Felipe Sateler]

On Sat, Apr 17, 2010 at 09:25, torbenh <torbenh at gmx.de> wrote:
>
> hi...

Hi Torben. (I'm CCing you because I don't know if you are subscribed).

>
> i just want to make sure you leave the option open
> to package alternative jack versions.
>
> adi said that you somehow seem to believe that
> there cant be virtual packages containing libraries.
>
> this is not true.
>
> if you create debian/libjack0.shlibs
> and put
> -----------------------------------
> libjack 0 WHATEVER
> ------------------------------------
>
> in it, this will get installed into
> /var/libs/dpkg/info/libjack0.shlibs
>
> and it will result in dh_shlibs generating
> WHATEVER as a dependency when it encouters something linked against
> libjack.so.0
>
> so its pretty easy to make libjack0 a virtual package.
> we already have 3 implementations of jack
> which are all ABI compatible.
> and we really want users to be able to use them.


Something like this is used for the ffmpeg package. However, for that
to work, virtual packages are not enough. Dependencies on shared
libraries are versioned, and versioned depends on virtual packages are
not supported by dpkg. For this to work, we would need to have the
names of the packages providing the alternative libraries. So, if the
default jack is in libjack0, then there could be libjack1-0,
libtschack0 packages that provide the different versions (and somehow
make the versioning between all three is consistent in the shlibs
file: libjack0 (>= a.b.c) | libjack1-0 (>= x.y.z) | libtschack0 (>=
f.g.h) ).


>
> its fine if the default is jack2. but please leave the door open for
> people who have problems with jack2 and are better off with tschack.

There is additional burden to packaging several versions of jack.
Unless someone takes that burden and packages another version of jack,
there is no point in making the debian package more complex. Are there
debian packages of these other versions of jack around?

>
> we (upstream) will make sure they are binary compatible.
> all symbols added since jack-0.116 are mandated to be weak.
> if there are any issues with binary compatibility these are bugs.

I'm not sure how weak symbols help binary compatibility. If I
understand weak symbols correctly, it enables an application to detect
if certain symbols are available and make use of them. How does that
ensure that an application built against one version is compatible
with another?

-- 

Saludos,
Felipe Sateler