Re: Bug#583916: Upcoming jack transition
On Thu, Jun 17, 2010 at 21:39:41 (CEST), Reinhard Tartler wrote: > Short status update: > > all three relevant (source) packages have been uploaded now: > > - jack-audio-connection-kit > - jackd2 > - jackd-defaults > > The transition can be started by processing them from new. I'd suggest > to process these three packages in a batch. After the upload, some additional problems have been found while discussing the packages on irc. I've incorporated Julien's and Adam's comments, and reuploaded then. AFAIUI, they are good to go now; I've done upgrade tests with apt and aptitude, and things seem to go as expected, more or less [1] [1] aptitude gets it right, apt seems to prefer to remove jackd, which AFAIUI can be solved by binNMU'ing qjackctl to make it pickup the new shlibdeps. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#583916: Upcoming jack transition
Short status update: all three relevant (source) packages have been uploaded now: - jack-audio-connection-kit - jackd2 - jackd-defaults The transition can be started by processing them from new. I'd suggest to process these three packages in a batch. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#583916: Upcoming jack transition
On Mon, Jun 14, 2010 at 11:51:44AM +0200, Reinhard Tartler wrote: > > From a quick look, the only potential issue with the j-a-c-k upload > > itself I can see is that it build-depends on python; however, as it > > doesn't produce any python modules and only appears to have a runtime > > dependency on the python package, I'm not sure this actually causes > > any problems in practice. > > I don't think that will be a problem. adi, jonas, can you comment on this? That's only for /usr/bin/jack_control, a python script that's used to control the DBUS version of jackd. HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#583916: Upcoming jack transition
On Mon, June 14, 2010 06:49, Reinhard Tartler wrote: > On Sat, Jun 12, 2010 at 16:57:52 (CEST), Adam D. Barratt wrote: > >> On Mon, 2010-05-31 at 18:39 +0200, Reinhard Tartler wrote: >>> This creates the situation that we actually partially revert the last >>> transition. However, we still consider jackd2 as the superior >>> implementation for squeeze, so we need to introduce a new virtual >>> package for the libjack0 library. We expect the actual rebuilds to be >>> rather smooth, since the jackd1 implementation was tested extensively >>> in >>> Lenny and Squeeze. >>> >>> It appears that 93 source packages will need to be binNMUd as part of >>> this transition. [...] >> Is there a solution which would allow us to perform a gradual rebuild of >> involved packages without potentially blocking other transitions? > > The transition does not need to be finished before some other transition > starts because we intend to retain the package 'libjack0' as non-virtual > package so that dependencies on this remain resolvable all the time. > > Is this what you've asked for or did I miss something? What I meant was, could we do something along the lines of: * upload new j-a-c-k package and whatever other sourceful changes are required * get the above built everywhere and migrated to testing asap * binNMU libjack0's r-deps a few at a time, letting them migrate to testing as and when they're ready and skipping any that will require rebuilds for other transitions anyway This would be much easier to fit in around other transitions than having to rebuild all of the r-deps before any of them could transition. From a quick look, the only potential issue with the j-a-c-k upload itself I can see is that it build-depends on python; however, as it doesn't produce any python modules and only appears to have a runtime dependency on the python package, I'm not sure this actually causes any problems in practice. Regards, Adam ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#583916: Upcoming jack transition
On Mon, Jun 14, 2010 at 11:14:22 (CEST), Adam D. Barratt wrote: > On Mon, June 14, 2010 06:49, Reinhard Tartler wrote: >> On Sat, Jun 12, 2010 at 16:57:52 (CEST), Adam D. Barratt wrote: >> >>> On Mon, 2010-05-31 at 18:39 +0200, Reinhard Tartler wrote: This creates the situation that we actually partially revert the last transition. However, we still consider jackd2 as the superior implementation for squeeze, so we need to introduce a new virtual package for the libjack0 library. We expect the actual rebuilds to be rather smooth, since the jackd1 implementation was tested extensively in Lenny and Squeeze. It appears that 93 source packages will need to be binNMUd as part of this transition. > [...] >>> Is there a solution which would allow us to perform a gradual rebuild of >>> involved packages without potentially blocking other transitions? >> >> The transition does not need to be finished before some other transition >> starts because we intend to retain the package 'libjack0' as non-virtual >> package so that dependencies on this remain resolvable all the time. >> >> Is this what you've asked for or did I miss something? > > What I meant was, could we do something along the lines of: > > * upload new j-a-c-k package and whatever other sourceful changes are > required > * get the above built everywhere and migrated to testing asap > * binNMU libjack0's r-deps a few at a time, letting them migrate to > testing as and when they're ready and skipping any that will require > rebuilds for other transitions anyway Yes, that looks OK for me. > This would be much easier to fit in around other transitions than having > to rebuild all of the r-deps before any of them could transition. Indeed, I agree. > From a quick look, the only potential issue with the j-a-c-k upload > itself I can see is that it build-depends on python; however, as it > doesn't produce any python modules and only appears to have a runtime > dependency on the python package, I'm not sure this actually causes > any problems in practice. I don't think that will be a problem. adi, jonas, can you comment on this? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#583916: Upcoming jack transition
On Sat, Jun 12, 2010 at 16:57:52 (CEST), Adam D. Barratt wrote: > On Mon, 2010-05-31 at 18:39 +0200, Reinhard Tartler wrote: >> This creates the situation that we actually partially revert the last >> transition. However, we still consider jackd2 as the superior >> implementation for squeeze, so we need to introduce a new virtual >> package for the libjack0 library. We expect the actual rebuilds to be >> rather smooth, since the jackd1 implementation was tested extensively in >> Lenny and Squeeze. >> >> It appears that 93 source packages will need to be binNMUd as part of >> this transition. >> >> We know that this is very very late for squeeze for which we apologize, >> but hope that it's not too late yet. Please give us a timeframe when we >> can start this transition with a new 'jack-audio-connection-kit' upload. > > It is indeed very late in the cycle to be introducing such a transition. > > I'm not quite clear where things were up to after the discussion of > Julien's suggestions, but we're trying to tie down as final a possible a > set of remaining transitions for Squeeze and this does seem like it > would cause us a significant number of rebuilds of packages that in some > cases will need to be rebuilt for other transitions anyway and aren't > always the smoothest to build (xmms2/armel had problems around the time > we were trying to get the directfb transition block migrated, for > example). I see. > Is there a solution which would allow us to perform a gradual rebuild of > involved packages without potentially blocking other transitions? The transition does not need to be finished before some other transition starts because we intend to retain the package 'libjack0' as non-virtual package so that dependencies on this remain resolvable all the time. Is this what you've asked for or did I miss something? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#583916: Upcoming jack transition
On Sun, Jun 6, 2010 at 10:12, Reinhard Tartler wrote: >> 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. To build against jackd1, it is necessary only that jack1 provides the non-virtual libjack-dev. The name of the library package itself is of no relevance, I think. Julien Cristau wrote: >> 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... libjack0 has a clearer ABI as it is pure C. It thus makes it easier to detect borkage. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#583916: Upcoming jack transition
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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#583916: Upcoming jack transition
Hi Reinhard, 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. [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. Cheers, Julien 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
Re: Bug#583916: Upcoming jack transition
On So, Jun 06, 2010 at 00:15:54 (CEST), Julien Cristau wrote: > On Sat, Jun 5, 2010 at 16:09:53 -0400, Felipe Sateler wrote: > >> On Sat, Jun 5, 2010 at 15:36, Julien Cristau wrote: >> > So I have a few questions about this plan: >> > - if all implementations of libjack are binary-compatible, then why do >> > we need to change the package name when changing implementations of >> > libjack? >> >> Because there can be only one package of a given name... unless I'm >> misparsing your question. >> > 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. >> > - related to this, the libjack0.symbols file currently has things like >> > 'jack_client_kill_thr...@base 1.9.5~dfsg-13' which suggest that it is, >> > actually, not completely compatible with other implementations (a >> > quick check suggests that nothing out of the jack-audio-connection-kit >> > source package uses these additional symbols, but..) >> > - many packages apparently depend on symbols labelled 0.118.0 or later >> > in the symbols file, how does that fly with a 0.116 jackd1? >> >> I believe the symbols file is borked. Client applications are only >> allowed to assume functions defined in 0.116 to exist. Extra symbols >> are defined as weak, and clients intending to use them must check for >> their availability. Clients assuming such symbols exist are broken >> according to upstream. >> >> So... libjack *can* have extra symbols added after the 0.116 API, and >> it *can* have extra symbols for use for the server. Client >> applications cannot assume they exist, though. >> > In that case I suggest changing libjack0 to: > - kill the .symbols file > - have the libjack0 package provide, replace and conflict with libjack0-0.116 > - have the libjack0.shlibs file point at 'libjack0 | libjack0-0.116' or > similar Agreed. > Then reverse deps can be gradually rebuilt. > > 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, 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. Moreover, this leaves us more options for squeeze+1, for which we haven't decided which will be the "best" jackd implementation. Do you still feel that this is overengineered? [1] in fact, there may also be regular applications that might also require "non-standard" features of jack that are not provided by the 0.116 ABI. In this case we expect such packages to install a more strict shlibs.local file to express this. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#583916: Upcoming jack transition
On Sat, Jun 5, 2010 at 16:09:53 -0400, Felipe Sateler wrote: > On Sat, Jun 5, 2010 at 15:36, Julien Cristau wrote: > > So I have a few questions about this plan: > > - if all implementations of libjack are binary-compatible, then why do > > we need to change the package name when changing implementations of > > libjack? > > Because there can be only one package of a given name... unless I'm > misparsing your question. > 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. > > - I understand you want to allow different jackd implementations to > > coexist. Do we really need 2 implementations of libjack as well? > > Yes. The server and the library have an internal API that is not > guaranteed to be compatible across any kind of release. So these two > must be the same upstream version. > OK. > > - related to this, the libjack0.symbols file currently has things like > > 'jack_client_kill_thr...@base 1.9.5~dfsg-13' which suggest that it is, > > actually, not completely compatible with other implementations (a > > quick check suggests that nothing out of the jack-audio-connection-kit > > source package uses these additional symbols, but..) > > - many packages apparently depend on symbols labelled 0.118.0 or later > > in the symbols file, how does that fly with a 0.116 jackd1? > > I believe the symbols file is borked. Client applications are only > allowed to assume functions defined in 0.116 to exist. Extra symbols > are defined as weak, and clients intending to use them must check for > their availability. Clients assuming such symbols exist are broken > according to upstream. > > So... libjack *can* have extra symbols added after the 0.116 API, and > it *can* have extra symbols for use for the server. Client > applications cannot assume they exist, though. > In that case I suggest changing libjack0 to: - kill the .symbols file - have the libjack0 package provide, replace and conflict with libjack0-0.116 - have the libjack0.shlibs file point at 'libjack0 | libjack0-0.116' or similar Then reverse deps can be gradually rebuilt. 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? Cheers, Julien 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
Re: Bug#583916: Upcoming jack transition
On Sat, Jun 5, 2010 at 15:36, Julien Cristau wrote: > On Mon, May 31, 2010 at 18:39:11 +0200, Reinhard Tartler wrote: > >> The last transition switched the jack-audio-connection-kit package >> from 'jackd' to 'jackd2'. 'jackd2' is a complete reimplementation of >> jackd in C++ with SMP support. Most importantly however, is an added >> feature that improves interoperability with pulseaudio. For this >> reason, we decided to make this version the default version for Squeeze. >> >> During testing, however, we discovered that this transition has been and >> still is a bit problematic. Besides some more or less known bugs in >> 'jackd2', it exposes a lot of additional (internal, C++ only) symbols, >> with which we are not comfortable at all. Moreover, we have been >> approached by upstream(s) with concerns that our current package does >> not make it easy for 3rd parties (may it be upstream or backports.org) >> to provide replacement packages for other jackd implementations. >> >> For this reason, we propose to: >> >> - revert the 'jack-audio-connection-kit' package to the jackd1 >> implementation >> >> - make this package the provider of libjack-dev, however the actual >> daemon will be packaged as 'jackd1' (currently jackd) >> >> - create a shlibs file that makes application packages depend on >> 'libjack0-0.116 | libjack0-0.118+svn3796 (>= 1:0.0116)' (or similar). >> This effectively defines a new virtual package 'libjack0-0.116' that >> is provided by any jack implementation that claims to be binary >> compatible with the 0.116 release of the original jack >> implementation. >> >> - have all packages that are linked against libjack recompiled to pick >> up the new shlibs >> >> - introduce the jackd2 implementation as a new source package 'jackd2'. >> The binary package name of this jack daemon will be 'jackd2', the >> library package will be 'libjack-jackd2-0' and (of course also) >> provide 'libjack0-0.116'. >> >> - introduce a new source package 'jackd-defaults' that generates a meta >> package 'jackd' which points to the default jack implementation, >> which will be jackd2 for Debian. >> > So I have a few questions about this plan: > - if all implementations of libjack are binary-compatible, then why do > we need to change the package name when changing implementations of > libjack? Because there can be only one package of a given name... unless I'm misparsing your question. > - I understand you want to allow different jackd implementations to > coexist. Do we really need 2 implementations of libjack as well? Yes. The server and the library have an internal API that is not guaranteed to be compatible across any kind of release. So these two must be the same upstream version. > - related to this, the libjack0.symbols file currently has things like > 'jack_client_kill_thr...@base 1.9.5~dfsg-13' which suggest that it is, > actually, not completely compatible with other implementations (a > quick check suggests that nothing out of the jack-audio-connection-kit > source package uses these additional symbols, but..) > - many packages apparently depend on symbols labelled 0.118.0 or later > in the symbols file, how does that fly with a 0.116 jackd1? I believe the symbols file is borked. Client applications are only allowed to assume functions defined in 0.116 to exist. Extra symbols are defined as weak, and clients intending to use them must check for their availability. Clients assuming such symbols exist are broken according to upstream. So... libjack *can* have extra symbols added after the 0.116 API, and it *can* have extra symbols for use for the server. Client applications cannot assume they exist, though. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#583916: Upcoming jack transition
On Mon, May 31, 2010 at 18:39:11 +0200, Reinhard Tartler wrote: > The last transition switched the jack-audio-connection-kit package > from 'jackd' to 'jackd2'. 'jackd2' is a complete reimplementation of > jackd in C++ with SMP support. Most importantly however, is an added > feature that improves interoperability with pulseaudio. For this > reason, we decided to make this version the default version for Squeeze. > > During testing, however, we discovered that this transition has been and > still is a bit problematic. Besides some more or less known bugs in > 'jackd2', it exposes a lot of additional (internal, C++ only) symbols, > with which we are not comfortable at all. Moreover, we have been > approached by upstream(s) with concerns that our current package does > not make it easy for 3rd parties (may it be upstream or backports.org) > to provide replacement packages for other jackd implementations. > > For this reason, we propose to: > > - revert the 'jack-audio-connection-kit' package to the jackd1 >implementation > > - make this package the provider of libjack-dev, however the actual >daemon will be packaged as 'jackd1' (currently jackd) > > - create a shlibs file that makes application packages depend on >'libjack0-0.116 | libjack0-0.118+svn3796 (>= 1:0.0116)' (or similar). >This effectively defines a new virtual package 'libjack0-0.116' that >is provided by any jack implementation that claims to be binary >compatible with the 0.116 release of the original jack >implementation. > > - have all packages that are linked against libjack recompiled to pick >up the new shlibs > > - introduce the jackd2 implementation as a new source package 'jackd2'. >The binary package name of this jack daemon will be 'jackd2', the >library package will be 'libjack-jackd2-0' and (of course also) >provide 'libjack0-0.116'. > > - introduce a new source package 'jackd-defaults' that generates a meta >package 'jackd' which points to the default jack implementation, >which will be jackd2 for Debian. > So I have a few questions about this plan: - if all implementations of libjack are binary-compatible, then why do we need to change the package name when changing implementations of libjack? - I understand you want to allow different jackd implementations to coexist. Do we really need 2 implementations of libjack as well? - related to this, the libjack0.symbols file currently has things like 'jack_client_kill_thr...@base 1.9.5~dfsg-13' which suggest that it is, actually, not completely compatible with other implementations (a quick check suggests that nothing out of the jack-audio-connection-kit source package uses these additional symbols, but..) - many packages apparently depend on symbols labelled 0.118.0 or later in the symbols file, how does that fly with a 0.116 jackd1? Overall this looks like a lot of churn, late in the release cycle, for an end result which seems quite close to the current situation. Cheers, Julien 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
