Bug#583916: Upcoming jack transition

[Reinhard Tartler]

On So, Jun 06, 2010 at 11:26:38 (CEST), Julien Cristau wrote:

> Hi Julien,
>
> On Sun, Jun  6, 2010 at 10:43:33 +0200, Reinhard Tartler wrote:
>
>> On So, Jun 06, 2010 at 00:15:54 (CEST), Julien Cristau wrote:
>> 
>> > Your proposal talked about introducing a libjack-jackd2-0 and a
>> > libjack0-0.118+svn3796 package, AIUI.  I don't understand why the
>> > current libjack0 package can't stay.
>> 
>> Hm. maybe I missed something here. So your idea is to have the original
>> 'jack1' package have the non-virtual package libjack0, right? The idea
>> was to make it easier in future to switch the jack implementation that
>> is used to build applications against. But I agree that this is not
>> really that important at this point. Moreover, I'm not even sure anymore
>> that we would want to do that, but that's future discussion, right.
>> 
> My idea was to have the j-a-c-k (jackd2) package provide the non-virtual
> package libjack0, just like today.  I didn't think it was important
> which libjack implementation apps build against, and this seemed the
> easiest / least disruptive way.

Well, we prefer (I think adi has expressed this explicitly) to have
applications built against jackd1. I think the easiest and most obvious
way for this is to make libjack0 a non-virtual package produced by
j-a-c-k (jackd1), and have a separate libjack-jackd2-0 package produced
by the (NEW) jackd2 source package.

> [snip]
>> > I'm not quite sure about the rest of the plan (switching the j-a-c-k
>> > package from one implementation to another one, introducing a
>> > jackd-defaults), it seems overengineered compared to leaving the current
>> > j-a-c-k package alone, and reintroducing jackd1 and its libjack
>> > alongside it.  Can you explain why you need all this?
>> 
>> The plan is to have 2 implementations of jackd2 in squeeze: jackd1 and
>> jackd2. Both badly need their 'own' implementation of libjack, while
>> regular applications don't care if they find libjack0 from jackd1 or
>> jackd2 at run time. [1]
>> 
>> For the default install, we want to install jackd2 by default as we
>> believe that it provides a superiour user experience. However, we want
>> to have all applications built against libjack0 from jackd1. Moreover,
>
> OK as I said above I don't understand this bit...
>
>> upstream has indicated that they want to provide backports for future,
>> more featureful jackd1 packages on their website. Therefore I've
>> imagined a jack-defaults package that can be overriden in that
>> repository. A user would then only have to 'apt-get dist-upgrade' and
>> have its jackd2 replaced by the newer jackd1 implementation.
>> 
> 'apt-get install jackd1' is not good enough?  If all apps are rebuilt
> with the new shlibs, then this should replace jackd2 and its libjack0
> with jackd1 and the corresponding lib, AFAICT.

Having a jack-defautls package would allow us to switch the default jack
implementation on upgrades. With your proposal, the user needs to
explicitly install the 'other' implementation.

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