packaging jack...

[Reinhard Tartler]

Puh, here goes another lengthy mail...

On Sat, Apr 17, 2010 at 20:31:46 (CEST), Felipe Sateler wrote:
> On Sat, Apr 17, 2010 at 09:25, torbenh <torbenh at gmx.de> wrote:
>> 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) ).

I've had a longer conversation with torben about this and my earlier
suggestion on irc. While we all agreed that from a distribution POV we
shouldn't provide more than one libjack implementation, he suggested a
further variant of the two already proposed approaches, which would
produce a shlibs file like this:

libjack0 (>= a.b.c) | libjack-0.116

and the libjack-0.116 would then be a virtual package, provided by all
jack implementations. It would them indicate a provided binary
interface. All (alternative) implementations would then need to
conflict/replace on libjack-0.116. This makes libjack-0.116 effectively
a pure virtual implementation like mail-transport-agent, cf. with policy
§7.6.2. Also note that we probably should then get this discussed on
debian-devel for inclusion in the official list of virtual packages as
indicated in §3.6 and [1].

[1] http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

I have never seen such a virtual package for shared libraries in the
wild so far. Before we do that, we would need to check if the
alternative implementations need to conflict on libjack0 explicitly, or
if conflict/providing on libjack-0.116 is sufficient.

NB: every jack daemon implementation would still need to carry a
very strict shlibs.local file to ensure that the daemon matches the
library it is compiled against!

NB2: this requires any applications with special requirements on a
specific jack implementation to ship a shlibs.local file.

>> 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?

The actual packaging is not that complex. The trouble comes with
supporting/testing all possible combinations of applications and
libjack/jackd implementations.

>> 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?

It doesn't ensure anything in applications, but upstream considers such
applications buggy that need to be fixed. The weak symbol approach
isn't really supported by dpkg-shlibdeps/dpkg-gensymbols, so we need to
take special care for them.

While we are at dpkg-gensymbols: in the irc conversation, Torben said
that he considers the leaked internal symbols as something that needs to
be fixed and asked them to be reported upstream. Jonas, please keep this
in mind, and the special situation of the 0.116 ABI freeze. AFAIUI, the
current jack packages calls dh_makeshlibdeps with '-V' (i.e., without
version bound). This seems very wrong to me, and should rather be bound
to the 0.116 version, and not to each and every new upload. As for
symbol files, please reconsider the situation with these pieces of
information, I still think that symbol files don't have much benefit
without further work on hiding internal symbol, which torben seems happy
to consider for inclusion!

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4