packaging jack...

[Jonas Smedegaard]

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.

Each implementation will have their own package names, and then in 
addition they will all claim to provide a _virtual_ package name called 
"libjack0.100.0".  So not like earlier (which was before I got involved 
in the team, so I only know of the result, not the considerations behind 
it).

If upstream had a more strict coding style (and if I understand it 
correctly, I am a scripter myself, not a coder, so looking at it from 
aside), then they would probably instead have bumped the SONAME and we 
would not use an odd version like this but just use "libjack1" as the 
tag name.

We could also use "libjack-2010" or "jack-lib-new-generation" if those 
better indicate what is common across the implementations.  Do upstream 
perhaps have an internal codename for the unification/freeze that we 
could reuse?


>>Later it might make sense to try support officially linking against 
>>alternate implementations. If that works out, it might make sense to 
>>repackage jackd1 similar to the others, so as to treat all 
>>implementations as equal competitors.  But that is post Squeeze IMO.
>
>An alternative to keep from holding up squeeze could be: keep things as 
>they are currently... with Jack 1.  Keep Jack 2 in sid (or something) 
>so users can upgrade to it if they want.  Meanwhile, the proposal 
>sounds odd because of the way that the package names relate and the 
>0.116.0 thing.

This is contained in my proposal: Just tag the newly added 
implementations with a dummy release-critical bugreport to keep them 
from trickling into testing and from there to stable, and you have 
"things as they are currently".

What I propose goes _beyond_ that, though.  It is a no-brainer to revert 
our git to status quo, but what then?  I did not put timestamps on each 
step but it _is_ an ordered list, and if some step fail or gets stalled, 
then the affected packages will not reach Squeeze in time for the 
release.  In other words, if something (or someone - e.g. ftpmaster) 
turns out to not work right, then what will for sure stay in the archive 
and get shipped with Squeeze be jackd1.


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


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/9221b35e/attachment.pgp>