packaging jack - details on "plan B"

[Jonas Smedegaard]

On Fri, Apr 23, 2010 at 02:29:00PM +0200, Reinhard Tartler wrote:
>On Wed, Apr 21, 2010 at 14:16:36 (CEST), Jonas Smedegaard wrote:
>>
>>>>  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?
>
>ping?

Sorry, not sure I understand the question.

Without virtually providing jackd, the jackd2 package does not, well, 
provide jackd.

It will work for packages just wanting _any_ jackd.  Packages like
Ardour that are picky about the version of jackd will need to 
explicitly
state which version of the alternative implementation (if at all) is
acceptable.

Did that answer your question?



>As indicated in the other mail, we have two objectives:
>
> a) switch the default implementation
> b) rearrange packaging to support switching the used implementation

[...]

>You seem to insist on deciding a) before b), while I'd rather see b) 
>implemented before a),

No, I explicitly as step 1 *postpone* switching.

Long term I want jackd2 as default.  I just do not want to switch before 
supportive mechanisms for multiple concurrent implementations are 
properly in place.

Seems we actually agree, just talk past each other here :-)


>> (I do feel that you suspect the grand plan to not work at all, so do 
>> not want to stop the current discussion, just want to warn about it 
>> exploding into all sorts of details not needed to discuss ahead)
>
> You're right, I fear step b) will be technically challenging and I 
> offer my experience from a similar trick in the FFmpeg packages to 
> review its implementation.

It seems you miss my point (contained in the paragraph above which you 
snipped, if I recall correctly):

If you feel that the plan is utterly broken, cannot work, will meet a 
dead end mid way, is impossible(!) to implement, then let us discuss 
fully and in detail untill either agreeing to drop the plan or agreeing 
that it seems doable.

If, on the other hand, you feel that the plan will be "technically 
challenging" but otherwise is sane, then I strongly suggest to not 
discuss in details all steps of it, but instead discuss when (or if) 
problems are spotted while implementing.




>> We could either just abandon the libjack0 and libjack-dev as real 
>> packages and only rely on virtual package names for 
>> build-dependencies of common-ABI-conforming projects.
>
>Which is more or less what I propose.

So my proposal does not conflict with yours, but optionally includes it.  
Great. :-)


>> Most likely this step is long after Squeeze.  And quite probably we 
>> won't do this step at all. Even if completely broken, I do not see 
>> failure of this step to affect any of the other steps. Is it relevant 
>> to discuss it in detail now?
>
>Yes, because I think we really can and should implement this for 
>squeeze!

You believe we can work fast, and therefore you want us to discuss more 
before we start working?  Even if we do not disagree on the steps, only 
on details within some of the (later) steps?



>> Do you only fear that I forgot some details, or do you fear that it 
>> is impossible to implement at all like I drafted, even with carefully 
>> composed package relations?
>
>I fear that your proposal would require all jack implementation 
>packages to be aware of all other "competing" implementation packages.

I fail to imagine how my *plan* could cause such situation.  It very 
much sounds like ugly _implementaiont_ of that plan.  And something that 
can easily be fixed by adjusting minor packaging hints - not something 
broken in the overall plan, and thus not something relevant to stall the 
work for discussing ahead IMHO.








>So yes, I'm more and more convinced that this should work.

"this" being your proposal or mine?  Or did I (again) misunderstand?


Kind regards,

  - 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/a6a5bbe8/attachment-0001.pgp>