[LAD] JACK for openSUSE 11.0 x86_64

Jussi Laako jussi at sonarnerd.net
Tue Dec 16 18:16:29 UTC 2008


oc2pus at arcor.de wrote:
>> STOP SPLITTING JACK UP.
> This "fetaure" was not packman's idea ... 
> 
> see openSuSE-shared-library policy:
> http://en.opensuse.org/Shared_Library_Packaging_Policy

This is one of the "bright" ideas adopted from Debian-based systems, but
I'm not at all convinced that it's a good idea especially in jack case.

Normally the reason for this is that older applications which depend on
older shared libraries can co-exist and work with newer applications
depending on newer shared libraries. However, for jack this creates a
conflict situation which might be hard for the end user to solve.

Reason is that the jack server and the shared library for clients are
tied to each other by specific version/layout of shared memory block
used to communicate. Even if dynamic linking dependency for older
applications wouldn't break and the application would continue to load,
they will stop actually functioning! For this particular reason there's
a specific way to handle also shared library versions. This is not done
for binaries, however!

Now this "bright" idea of "let's not break old binaries, let's just
install bunch of different versions of the same library" is doomed for
jack (and for many other non-self-contained apps too). It doesn't take
into account the dependency between the server version and certain
client library version. And even more confusing for the user would be to
have two different server versions with applications for two different
library versions and the user would start wondering why he cannot route
audio between different applications, etc...

> This shared library policy needs a lot of extra-work but it allows also to 
> update library packages without breaking existing packages and or 
> mass-rebuilds if a so-name of a library is changed (ffmpeg-libs, x264 are 
> well known candidates for changing often API).

That's especially what it doesn't achieve with jack. It specifically
breaks things, badly...


BR,

	- Jussi



More information about the Linux-audio-dev mailing list