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 andI 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
signature.asc
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
