On Fri, Apr 23, 2010 at 02:29:00PM +0200, Reinhard Tartler wrote:
On Wed, Apr 21, 2010 at 14:16:36 (CEST), Jonas Smedegaard wrote: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?ping?
Sorry, not sure I understand the question.Without virtually providing jackd, the jackd2 package does not, well, provide jackd.
It will work for packages just wanting _any_ jackd. Packages likeArdour that are picky about the version of jackd will need to explicitly
state which version of the alternative implementation (if at all) is acceptable. Did that answer your question?
As indicated in the other mail, we have two objectives: a) switch the default implementation b) rearrange packaging to support switching the used implementation
[...]
You seem to insist on deciding a) before b), while I'd rather see b) implemented before a),
No, I explicitly as step 1 *postpone* switching.Long term I want jackd2 as default. I just do not want to switch before supportive mechanisms for multiple concurrent implementations are properly in place.
Seems we actually agree, just talk past each other here :-)
(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)You're right, I fear step b) will be technically challenging and I offer my experience from a similar trick in the FFmpeg packages to review its implementation.
It seems you miss my point (contained in the paragraph above which you snipped, if I recall correctly):
If you feel that the plan is utterly broken, cannot work, will meet a dead end mid way, is impossible(!) to implement, then let us discuss fully and in detail untill either agreeing to drop the plan or agreeing that it seems doable.
If, on the other hand, you feel that the plan will be "technically challenging" but otherwise is sane, then I strongly suggest to not discuss in details all steps of it, but instead discuss when (or if) problems are spotted while implementing.
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.Which is more or less what I propose.
So my proposal does not conflict with yours, but optionally includes it. Great. :-)
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?Yes, because I think we really can and should implement this for squeeze!
You believe we can work fast, and therefore you want us to discuss more before we start working? Even if we do not disagree on the steps, only on details within some of the (later) steps?
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?I fear that your proposal would require all jack implementation packages to be aware of all other "competing" implementation packages.
I fail to imagine how my *plan* could cause such situation. It very much sounds like ugly _implementaiont_ of that plan. And something that can easily be fixed by adjusting minor packaging hints - not something broken in the overall plan, and thus not something relevant to stall the work for discussing ahead IMHO.
So yes, I'm more and more convinced that this should work.
"this" being your proposal or mine? Or did I (again) misunderstand? 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
