On So, Jun 06, 2010 at 11:26:38 (CEST), Julien Cristau wrote: > Hi Julien, > > On Sun, Jun 6, 2010 at 10:43:33 +0200, Reinhard Tartler wrote: > >> On So, Jun 06, 2010 at 00:15:54 (CEST), Julien Cristau wrote: >> >> > Your proposal talked about introducing a libjack-jackd2-0 and a >> > libjack0-0.118+svn3796 package, AIUI. I don't understand why the >> > current libjack0 package can't stay. >> >> Hm. maybe I missed something here. So your idea is to have the original >> 'jack1' package have the non-virtual package libjack0, right? The idea >> was to make it easier in future to switch the jack implementation that >> is used to build applications against. But I agree that this is not >> really that important at this point. Moreover, I'm not even sure anymore >> that we would want to do that, but that's future discussion, right. >> > My idea was to have the j-a-c-k (jackd2) package provide the non-virtual > package libjack0, just like today. I didn't think it was important > which libjack implementation apps build against, and this seemed the > easiest / least disruptive way.
Well, we prefer (I think adi has expressed this explicitly) to have applications built against jackd1. I think the easiest and most obvious way for this is to make libjack0 a non-virtual package produced by j-a-c-k (jackd1), and have a separate libjack-jackd2-0 package produced by the (NEW) jackd2 source package. > [snip] >> > I'm not quite sure about the rest of the plan (switching the j-a-c-k >> > package from one implementation to another one, introducing a >> > jackd-defaults), it seems overengineered compared to leaving the current >> > j-a-c-k package alone, and reintroducing jackd1 and its libjack >> > alongside it. Can you explain why you need all this? >> >> The plan is to have 2 implementations of jackd2 in squeeze: jackd1 and >> jackd2. Both badly need their 'own' implementation of libjack, while >> regular applications don't care if they find libjack0 from jackd1 or >> jackd2 at run time. [1] >> >> For the default install, we want to install jackd2 by default as we >> believe that it provides a superiour user experience. However, we want >> to have all applications built against libjack0 from jackd1. Moreover, > > OK as I said above I don't understand this bit... > >> upstream has indicated that they want to provide backports for future, >> more featureful jackd1 packages on their website. Therefore I've >> imagined a jack-defaults package that can be overriden in that >> repository. A user would then only have to 'apt-get dist-upgrade' and >> have its jackd2 replaced by the newer jackd1 implementation. >> > 'apt-get install jackd1' is not good enough? If all apps are rebuilt > with the new shlibs, then this should replace jackd2 and its libjack0 > with jackd1 and the corresponding lib, AFAICT. Having a jack-defautls package would allow us to switch the default jack implementation on upgrades. With your proposal, the user needs to explicitly install the 'other' implementation. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
