packaging jack - details on "plan B"

[Jonas Smedegaard]

On Wed, Apr 21, 2010 at 12:26:41PM +0200, Reinhard Tartler wrote:
>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.

"Switch to jackd2, no matter the costs" is silly.  I propose to "do our 
best to ship next distro release with jackd2 support", and do not feel 
like stabbing anyone by juggling that wording - now that the world of 
(j|ch)ack(d[12])? turned out to be more complex, post the cross-distro 
agreements.

But let us discuss strategy and implementation separately: Please do 
*not* reply to this email regarding cross-distro coordination strategy, 
but comment on my other recent email in another forked subthread. :-)


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

Yes, correct.

But an important detail is that I do *not* introduce that virtual 
package to the currently stable jackd1 packaging, only to newly 
introuced jackd2 and tchack packagings!

Only when proven reliable do I want to "infect" the stable package or 
other jack-dependent packages!

The reason for this is the logic of molding a new Debian releaase: It is 
much easier to rip out newly introduced oddities with not depended on by 
other already-accepted packages, than it is to fix problems involving 
chains of package rebuilds.

This also means we do not need to set it all in stone: we do not need to 
discuss *now* what exact wording of each shlib file or naming of virtual 
packages - only if suspected to not work at all is it relevant to 
discuss *now*, else we move faster if discussing and implementing in 
parallel.

(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)


>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

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.  

If it truly is irrelevant if a jack-dependent package build against 
jackd1, jackd2 or tchack, then it might (or might not!) make sense to 
stop promoting jackd1 as the most rightous of the implementations. 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. Or we can create a set of empty 
meta-packages e.g. libjack-abi-0.116.0 and libjack-abi-0.116.0-dev, 
depending on the implementations truly obeying the declared ABI - making 
it possible to ease transition to newer ABI if API does not change, even 
if not all implementations do not switch to that newer API at the exact 
same time (or maybe some of them not at all).

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?


>>  4. Release jackd1 to experimental, with libjack0 providing   virtual
>> package libjack0-0.116.0
>
>Repeated step 4? Or copy & paste mistake?

copy'n'paste mistake :-)


Ohhhhh - now I realize why I had to defend above non-important step that 
much: all of those duplicated steps 4-5-4-5 should have been deleted.

Please ignore them as vague fluffy ideas for a bright future post 
Squeeze:  Only the initial steps 1-2-3-4 are part of my proposal.

...and even those 4 initial steps may eventually some of them reach 
beyond Squeeze.


>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 I understand your concern correctly, it is easily handled using 
"Replaces:".

I deliberately did not go into such details, as I can easily imagine 
lots of details being forgotten, but cannot imagine it eventually done 
right.

In other words: 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?



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

Sorry, I lost track: Could you please, in a differently named subthread, 
repeat your proposal?


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/20100421/e4f6c5ef/attachment.pgp>