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 jackd1As 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 privatelySo 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 libjack0Ah, 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.0what 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.0Repeated 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
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
