I'm new to the details of deb packaging... so I may be
replying to the wrong snippets... but:
Yes, something like that.
4. Release jackd1 to experimental, with libjack0 providing virtual
5. Repackage jackd1 to experimental, with libjack0 providing virtual
what actual changes are involved in this repackaging?
This step is not needed for technical reasons but was included for
potential political reason: not in the long term emphasize jackd1 as
being better than the other implementations.
Then let's make all applications to depend on 'libjack0-0.116.0', which
refers to the ABI, and provide a package 'jack-defaults', which builds a
meta-package 'jackd' which depends on the distribution chosen 'default'
I don't understand why we're emphasizing the ABI of
According to the Jack devs, a program compiled against Jack
0.34.0 (released ca. 2001) is still binary-compatible with
/any/ Jack implementation (whether Jack1, Jack2, tschack,
etc.) They have rigorously been maintaining this.
Therefore, any old program will work without recompile on a
new libjack0. Jack 2 (formerly jackdmp) has also rigorously
maintained binary compatability with Jack 1.
Therefore, the virtual package should be `libjack0', not
`libjack0-0.116.0'. See also  and .
Also, I'm sure you're on top of it, but it's important that
$ gcc -o foo `pkg-config --cflags --libs jack` foo.cpp
...does the right thing with:
$ dpkg-shlibdeps foo
 Going backwards has never been promised, though. A
program compiled against 0.118.0 will work with 0.34.0.
However, the use of weak symbols for new features may
make this available.
pkg-multimedia-maintainers mailing list