Hi guys,

I'm new to the details of deb packaging... so I may be replying to the wrong snippets... but:

Package:   libjack-jackd2-0
Provides:  libjack-0.116.0
Conflicts: libjack0

Yes, something like that.

 4. Release jackd1 to experimental, with libjack0 providing   virtual
package libjack-0.116.0
 5. Repackage jackd1 to experimental, with libjack0 providing   virtual
package libjack0-0.116.0

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'
jack implementation.

I don't understand why we're emphasizing the ABI of `libjack0-0.116.0'.

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.[3]

Therefore, the virtual package should be `libjack0', not `libjack0-0.116.0'. See also [1] and [2].

Also, I'm sure you're on top of it, but it's important that this:

    $ gcc -o foo `pkg-config --cflags --libs jack` foo.cpp

...does the right thing with:

    $ dpkg-shlibdeps foo


[1] http://trac.jackaudio.org/wiki/SuggestedPackagingApproach
[2] http://subversion.jackaudio.org/jack/tags/RELEASE_0_118_0/README.developers
[3] 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

Reply via email to