[LAD] JACK for openSUSE 11.0 x86_64

oc2pus at arcor.de oc2pus at arcor.de
Tue Dec 16 19:11:47 UTC 2008


Am Dienstag, 16. Dezember 2008 schrieb Jussi Laako:
> 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...

Ok, I uploaded new packages for jack and jack2.
They are now mutually exclusive and the user must change wich one to use. 
Formerly jack2 was handled as a update to jack.

The "Requires" to the underlying library packages where already part of the 
packman packages.

> BR,
>
> 	- Jussi



More information about the Linux-audio-dev mailing list