packaging jack - cross-distro coordination

Fri Apr 23 20:11:15 UTC 2010

On Fri, Apr 23, 2010 at 01:48:01PM +0200, Reinhard Tartler wrote:
>On Wed, Apr 21, 2010 at 13:30:55 (CEST), Jonas Smedegaard wrote:
>
>>>>> I don't understand the libjack-0.116.0 thing.  Is that going to be 
>>>>> the package name?  If so, that sounds like we would be repeating 
>>>>> the libjack0.100.0 mistake.
>>>>
>>>> It is more like an add-on tag, indicating the library ABI.
>>>
>>> I deduce from this that you don't want to adjust the shlibs file of 
>>> libjack package to make application package generate dependencies on 
>>> libjack-0.116.0 then?
>>
>> No, I want to adjust shlibs file later on, but not required for step 
>> 1.
>
>I don't see a reason to delay this. Details follow.

Understood (although I do not agree).  Sorry for too simplified summary 
of options - that was not intentional.

>> Generally speaking [...], I see 3 possible ways forward:
>>
>>  * conservative: Stay with jackd1, ignoring jackd2 and tchack.
>>  * stubborn: Switch to jackd2, abandoning jackd1 and ignoring tchack.
>>  * bold: switch to supporting multiple implementations.
>>
>> You seem to want the stubborn path, because a cross-distro wave have 
>> set off.
>
>I think adi should decide on this. And AFAIUI, adi has already decided 
>to go with jackd2. He visited me a few weeks ago at my workplace here 
>(he happened to be around for a workshop at my university) and we 
>discussed the pro and cons for the various jack implementations. His 
>arguments were pretty convincing that jackd2 was the best 
>implementation for squeeze.
>
>NB: I don't use jack myself, so I don't consider myself qualified to 
>actually backup such a decision. I just point out the results of the 
>previous discussions on this topic.

Regarding earlier decision:

I believe previous discussions could be summarized as this list of 
choices:

   a) Release Squeeze only with jackd1
   b) Release Squeeze only with jackd2, replacing jackd1

I got the impression that even if an option of shipping with both was 
discussed briefly, it died due to a general assumption that jackd2 was 
the natural successor of jackd1 and thus keeping both around would only 
be for the sake of slower transistion (i.e. irrelevant if a faster 
switch was deemed realistic).

Regarding options:

Let me try summarize anew, given my new understanding (dropping 
potentially provocative names):

   a) Stay with jackd1, ignoring jackd2 and tchack.
   b) Switch to jackd2, abandoning jackd1 and ignoring tchack.
   c) switch to supporting multiple implementations.

Let me try summarize anew, given my new understanding (dropping 
potentially provocative names):

   a) Release Squeeze only with jackd1
   b) Release Squeeze only with jackd2, replacing jackd1
   c) Release Squeeze with jackd1 as default, and optionally jackd2
   d) Release Squeeze with jackd2 as default, and optionally jackd1

I agree that adi already decided on b).  But at a time when jackd1 
seemed dying and jackd2 its natural replacement - just a question of 
when to switch.  Options like c) and d) was only considered as a more 
gentle transition method, which was later deemed unnecessary.

In other words, it is not my impression that adi already decided on d).

I do not want jackd1 as default due to being best, but due to being most 
tested.  We are close to release, so any radical is risky.

Switching from jackd1 to jackd2 as default (or only) library and daemon 
is a radical change, which we agreed to do anyway.

Implementing support for multiple implementations of the JACK interfaces 
is yet another radical change.

Two radical changes is one too many IMHO.

Replacing jackd1 because we consider it obsolete seemed a valid argument 
for me to take the risk.  But doing it not because we consider it 
obsolete but because we consider it still valid just less interesting is 
too weak argument for a too big risk this late in the game IMO.

I sincerely want jackd2 as default in a multi-implementation scenario.  
I just feel that we are too close to release to make multiple risky 
steps.

You (or adi?) want this:

   1) replace jackd1 with jackd2
   2) readd jackd1 differently named as optional alternative

Both of those are risky: The first might reveal problems when 
recompiling against claimed compatible but potentially not in reality 
compatible library API and daemon runtime ABI.  The second might cause 
problems in designing package interrelations correctly, and (depending 
on degree of offered replacements) linking and compiling issues as well.

I want this instead:

   1) keep jackd1 as is at first
   2) add jackd2 as optional alternative
   3) switch around to have jackd2 as default

At each step we may run out of time and ship that with Squeeze.  It 
makes better sense for me to risk shipping only something too boring for 
professionals to use but not broken, rather than something maybe broken 
and not discovered as such in time because we were busy complicating 
things even furthere.

>> I wanted to push jackd2 back when it was seen as the only future, 
>> only a question on when to make the switch.  But when it turns out 
>> jackd1 is intended to be kept alive or and tchack exist as a third 
>> possible future, I find it wrong to pick a single future immaturely.
>
>The future in the short term seems to including competing yet binary 
>compatible implementations of jack.

I do not expect us to reach to goal of properly handling multiple 
competing JACK implementations in time for the freeze of Squeeze!

>We as a distribution can (and I think also should) fulfill the 
>following goals:
>
> - decide on a default implementation
> - allow users to switch and use a non-default implementation

Yes.  I wholeheartedly agree.  But find it insane to set such high goal 
for the release of Squeeze.

We _might_ reach that noble goal in time.  But if we only get half way 
there, we should have something sane, not something with too high risk 
of being broken.

Ok, I'll stop now.  I keep repeating myself. :-/

  - Jonas

-- 
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100423/2f4e1cfb/attachment.pgp>