packaging jack - cross-distro coordination

[Jonas Smedegaard]

On Wed, Apr 21, 2010 at 12:09:50PM +0200, Reinhard Tartler wrote:
>On Wed, Apr 21, 2010 at 09:45:22 (CEST), Jonas Smedegaard wrote:
>
>> On Tue, Apr 20, 2010 at 07:48:26PM -0500, Gabriel M. Beddingfield wrote:
>>
>>>On Tue, 20 Apr 2010, Jonas Smedegaard wrote:
>>>
>>>>Let me then adjust and refine my proposal (main point is the same):
>>>[snip]
>>>>
>>>> It was suggested to discuss the introduction of the virtual 
>>>> libjack-0.116.0 on d-devel.  I consider that unnecessary as it is 
>>>> coordinated only amongst 3 packages that are all maintained by us. 
>>>> But if someone finds it relevant and
>>>
>>> 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.

But let us keep subdiscussions apart: Please do *not* respond to this 
email regarding to technical details of my proposed plan, but wait for a 
separate email (a response to your other recent email).


[enlightening details on upstream coding style snipped]


>>> Right now going from jack1->jack2 is a clean upgrade because of the 
>>> version numbers... so (for me) that would be fine. This all hit the 
>>> fan because it's hard for users to go from jack2->jack1 because they 
>>> have to force a downgrade.... and the LAD list was told that squeeze 
>>> would ship with Jack 2.
>>
>> Indeed.  My proposal puts first priority on keeping what we know is 
>> stable (and what turns out to not be abandoned upstream after all), 
>> and it puts second a way to try switch not only from one 
>> implementation to one other (that's easy) but from a single 
>> implementation to a choice of multiple ones.  Not multiple ones 
>> installed concurrently, but multiple mutually conflicting ones 
>> available for installation concurrently.
>
>So to put straight: you propose to not switch to jackd2 at all but 
>stick with jackd1? I guess you are aware that adi has negotiated with 
>opensuse to do a coordinated switch to jackd2, and is currently trying 
>to agree on something similar with fedora? I think that stepping back 
>from this plan would makes us look, well, strange.

I want to switch, but a) without lock-in on jackd2 (since that has 
turned out to not be the only potential future) and b) without 
geopardizing the release process.

Generally speaking (please let us discuss technical details in a 
separate subthread - I will fork one when done writing this), 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 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.

So I want to keep jackd1 alive and _then_ include jackd2, not include 
jackd2 as replacement for jackd1.  Which means there is a _risk_ that 
jackd2 will not reach inclusion into Squeeze.


In other words, I propose a 4th path:

  * cautious: first conservative, then gradually bolder.


Others looking strangely at Debian is nothing new: When I started using 
Debian in the last millenium, Redhat and SuSE users emphasized the 
weirdness of Debian not using upstream library naming but renaming to 
make it possible to handle multiple ABIs (or whatever it is called, not 
important here) in the distribution - either concurrently installable or 
conflicting but at least available in same release of the distro.


  - 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/8804f6f1/attachment.pgp>