packaging jack...

Reinhard Tartler siretart at tauware.de
Wed Apr 21 10:26:41 UTC 2010


On Tue, Apr 20, 2010 at 10:17:42 (CEST), Jonas Smedegaard wrote:

> On Sat, Apr 17, 2010 at 09:32:47PM +0200, torbenh wrote:
>>On Sat, Apr 17, 2010 at 09:13:34PM +0200, Jonas Smedegaard wrote:
>
>>> I propose to stick to jackd1 as the default/only library for other
>>> packages to rely on until the rerlease of Squeeze, and only offer
>>> alternative daemons (and eventually - most likely post-Squeeze - 
>>> alternative libraries too) if they do not interfere with that.
>>
>>stop right here.
>>the library and the daemon are tied together.
>>the protocol between jackd and libjack is NOT fixed.
>
> Ok, my mistake.
>
> Let me then adjust and refine my proposal (main point is the same):
>
>  1. Release src:jack-audio-connection-kit to unstable:
>     * revert to track only jackd1

As said in my other mail, I don't think we have this option anymore.
Doing so would be like stabbing in adi's wrt. his cross-distro
coordination on jackd2.

>  2. Initially release src:jackd2:
>     * jackd2 conflicts/replaces/provides jackd
>     * libjack0-jackd2 conflicts/replaces libjack0
>     * libjack0-jackd2 provides libjack-0.116.0
>     * libjack-jackd2-dev conflicts libjack-dev
>     * Big fat warning to use -dev package only privately

So you propose to introduce 2 virtual packages: jackd and
libjack-0.116.0? What problem does introducing the virtual package jackd
solve?

>  3. Initially release src:tchack, like jackd2
>  4. Update jack-depending packages after testing that it works:
>     * Add libjack-0.116.0 as fallback-dependency for libjack0

Ah, so at this point you propose to introduce a shlibs file like:

,----[proposed shlibs file]
| libjack0 0 libjack0 (>= 0.116) | libjack-0.116.0
`----

is that correct?

How is the libjack0 package from other implementations supposed to look
like? Something like this?

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

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

>  4. Release jackd1 to experimental, with libjack0 providing   virtual
> package libjack0-0.116.0

Repeated step 4? Or copy & paste mistake?


With you're proposal, I think switching from one alternative
implementation to another one won't work. For example switching from
tschack to jackd3 would break with undeclared file conflicts AFAIUI. And
my understanding of this whole hickhack was to allow users to switch
jack implementations without having to recompile packages.


(If it works) my idea would allow this; and without having each and
every implementation to declare conflicts against every existing other
implementation.


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



More information about the pkg-multimedia-maintainers mailing list