Re: packaging jack - details on "plan B"
On Mon, 26 Apr 2010, Jonas Smedegaard wrote: On Mon, Apr 26, 2010 at 9:20 AM, Gabriel M. Beddingfield wrote: ABI back-compatibility has never been assured - if a program was linked against JACK API M.N.m and the runtime installation is a version earlier than that, there may be problems as you noted. the new rules on weak symbols post the 0.118.0 API should help address this. Do I understand above correctly so that in fact jackd2 1.9.5 cannot be trusted to support library API (and ABI) of 0.116.2 but only that of 0.118.0? Correct. If you compiled against the libs from 0.100.0, 0.109.0, 0.116.2, 0.118.0, etc. it will work fine with 1.9.5. If you compiled against the libs from 1.9.5, it will work fine with >= 0.118.0. -gabriel ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging jack - details on "plan B"
On Mon, Apr 26, 2010 at 9:20 AM, Gabriel M. Beddingfield wrote: ABI back-compatibility has never been assured - if a program was linked against JACK API M.N.m and the runtime installation is a version earlier than that, there may be problems as you noted. the new rules on weak symbols post the 0.118.0 API should help address this. Do I understand above correctly so that in fact jackd2 1.9.5 cannot be trusted to support library API (and ABI) of 0.116.2 but only that of 0.118.0? Tell me if better that I ask upstream such questions. For now I would prefer this list acting as proxy for my perhaps too silly[1] questions. - Jonas [1] No question is too silly to be asked, I know. But some might be silly enough that others than busy upstream developers can answer. :-) -- * 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
Re: packaging jack - details on "plan B"
On Mon, Apr 26, 2010 at 08:29:40AM -0500, Gabriel M. Beddingfield wrote: On Sun, 25 Apr 2010, Jonas Smedegaard wrote: I notice, though, that above links only mention API, not ABI. Is it safe to expect library ABI (runtime linkage) to be frozen too if its API (compile time interface) is? I'm sure that the answer is "yes," but I've asked the upstream devs to confirm it. Cool! - 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
Re: packaging jack - details on "plan B"
On Sun, 25 Apr 2010, Jonas Smedegaard wrote: I notice, though, that above links only mention API, not ABI. Is it safe to expect library ABI (runtime linkage) to be frozen too if its API (compile time interface) is? Answer from upstream: Date: Mon, 26 Apr 2010 09:34:26 -0400 From: Paul Davis To: Gabriel M. Beddingfield Cc: Jack-Devel Subject: Re: [Jack-Devel] packaging jack - details on "plan B" (fwd) On Mon, Apr 26, 2010 at 9:20 AM, Gabriel M. Beddingfield wrote: Jack Devs: Please see the below e-mail (from debian packaging list) where Jonas would like a clarification about Jack's ABI compatability. I'm sure the answer is "yes"... but I wanted to check with you guys one more time. he asked "I notice, though, that above links only mention API, not ABI. Is it safe to expect library ABI (runtime linkage) to be frozen too if its API (compile time interface) is?" I think that the answer is "yes". Certainly I am not aware of any cses where switching from one version of JACK to another has caused ABI issues. We've never had it as a hard, explicit rule that development would follow this rule, but its always been an implicit goal and is a fairly natural consequence of the development pattern for JACK. again, this clearly only applies in the "upward" case - ABI back-compatibility has never been assured - if a program was linked against JACK API M.N.m and the runtime installation is a version earlier than that, there may be problems as you noted. the new rules on weak symbols post the 0.118.0 API should help address this. --p ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging jack - details on "plan B"
Hi Jonas, On Sun, 25 Apr 2010, Jonas Smedegaard wrote: I notice, though, that above links only mention API, not ABI. Is it safe to expect library ABI (runtime linkage) to be frozen too if its API (compile time interface) is? I'm sure that the answer is "yes," but I've asked the upstream devs to confirm it. -gabriel ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging jack - details on "plan B"
On Mon, Apr 26, 2010 at 04:38:17 (CEST), Felipe Sateler wrote: > On Sun, Apr 25, 2010 at 14:27, Reinhard Tartler wrote: >> On Sun, Apr 25, 2010 at 19:47:47 (CEST), Jonas Smedegaard wrote: >> >>> I notice, though, that above links only mention API, not ABI. Is it >>> safe to expect library ABI (runtime linkage) to be frozen too if its API >>> (compile time interface) is? >> >> Generally speaking, yes. >> >> (well, unless there are toolchain changes, etc. - very unlikely at this >> stage of squeeze) > > Not really. Reordering of enums, for example, could break ABI while > keeping API compatibility. Same with adding/reordering struct members. > Not relally common, but can happen. Oh, you're totally right. Somehow I considered these changes as API change as well, but what is meant here is a change that does not affect buildability. Other API compatible changes in C++ would e.g. include addition of additional parameters to existing methods with default parameters. This would affect ABI as well. I was clearly confused yesterday, sorry. -- 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: packaging jack - details on "plan B"
On Sun, Apr 25, 2010 at 14:27, Reinhard Tartler wrote: > On Sun, Apr 25, 2010 at 19:47:47 (CEST), Jonas Smedegaard wrote: > >> I notice, though, that above links only mention API, not ABI. Is it >> safe to expect library ABI (runtime linkage) to be frozen too if its API >> (compile time interface) is? > > Generally speaking, yes. > > (well, unless there are toolchain changes, etc. - very unlikely at this > stage of squeeze) Not really. Reordering of enums, for example, could break ABI while keeping API compatibility. Same with adding/reordering struct members. Not relally common, but can happen. -- 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: packaging jack - details on "plan B"
On Sun, Apr 25, 2010 at 19:47:47 (CEST), Jonas Smedegaard wrote: > I notice, though, that above links only mention API, not ABI. Is it > safe to expect library ABI (runtime linkage) to be frozen too if its API > (compile time interface) is? Generally speaking, yes. (well, unless there are toolchain changes, etc. - very unlikely at this stage of squeeze) -- 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: packaging jack - details on "plan B"
On Fri, Apr 23, 2010 at 03:36:02PM -0500, Gabriel M. Beddingfield wrote: Hi Jonas, On Fri, 23 Apr 2010, Jonas Smedegaard wrote: [3] Going backwards has never been promised, though. A program compiled against 0.118.0 will work with 0.34.0. However, the use of weak symbols for new features may make this available. Isn't it exactly "going backwards" if jackd2 becomes the default and jackd1 only an optional alternative? Then applications are compiled against jackd2 and potentially using jackd1 at runtime. Is that assured to work too, or only hopefully working if weak symbols work out as planned? Jack2/Jack1 are API-synchronized. Here are the sync points that have been published: JACK1JACK2 REF --- - 0.118.0 1.9.4 [1] 0.116.2 1.9.1 [2], [3] It is reasonable to expect that a program compiled against Jack2 1.9.1 will work fine with 0.116.2. Note also that the API changes since 0.109.0 (the first stable JACK MIDI release) have been minor. (Adding weak symbols, internal changes, documentations, internal header reorg.) HTH, Gabriel [1] http://jackaudio.org/node/28 [2] http://jackaudio.org/node/23 [3] http://jackaudio.org/node/22 Thanks for the clarification. I notice, though, that above links only mention API, not ABI. Is it safe to expect library ABI (runtime linkage) to be frozen too if its API (compile time interface) is? 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
Re: packaging jack - details on "plan B"
On Sat, Apr 24, 2010 at 02:18:16AM +0200, Adrian Knoth wrote: On Fri, Apr 23, 2010 at 05:52:35PM -0500, Gabriel M. Beddingfield wrote: On Fri, Apr 23, 2010 at 02:32:45PM -0500, Gabriel M. Beddingfield wrote: [1] http://trac.jackaudio.org/wiki/SuggestedPackagingApproach Note that this is a wiki and the suggestions come from only one person. True, but Nedko (the author of the article) shouldn't be ignored. He is very knowledgeable and respected in the LAD/Jack communities. Furthermore, he is saying the exact same thing that Torben and I have been saying. I mostly agree with the suggested packaging except "jackd", "jackdbus" and "jack server library" being separate packages. Not that it'd be wrong, but the amount of packages seems unnecessarily high. There are even people who suggest to put everything in a single jackd1/jackd2 package, but we probably don't want to go this far. I actually am positive about separateing into more packages like that. But let's discuss that later, after switch to jackd2 is in place. I.e. please remind me if I forget myself to get back to this issue :-) 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
Re: packaging jack - details on "plan B"
On Fri, Apr 23, 2010 at 05:52:35PM -0500, Gabriel M. Beddingfield wrote: >> On Fri, Apr 23, 2010 at 02:32:45PM -0500, Gabriel M. Beddingfield wrote: >>> [1] http://trac.jackaudio.org/wiki/SuggestedPackagingApproach >> >> Note that this is a wiki and the suggestions come from only one person. > > True, but Nedko (the author of the article) shouldn't be ignored. He is > very knowledgeable and respected in the LAD/Jack communities. > > Furthermore, he is saying the exact same thing that Torben and I have > been saying. I mostly agree with the suggested packaging except "jackd", "jackdbus" and "jack server library" being separate packages. Not that it'd be wrong, but the amount of packages seems unnecessarily high. There are even people who suggest to put everything in a single jackd1/jackd2 package, but we probably don't want to go this far. -- 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: packaging jack - details on "plan B"
On Fri, 23 Apr 2010, Eric Dantan Rzewnicki wrote: On Fri, Apr 23, 2010 at 02:32:45PM -0500, Gabriel M. Beddingfield wrote: [1] http://trac.jackaudio.org/wiki/SuggestedPackagingApproach Note that this is a wiki and the suggestions come from only one person. True, but Nedko (the author of the article) shouldn't be ignored. He is very knowledgeable and respected in the LAD/Jack communities. Furthermore, he is saying the exact same thing that Torben and I have been saying. Thanks, Gabriel ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging jack - details on "plan B"
On Fri, Apr 23, 2010 at 02:32:45PM -0500, Gabriel M. Beddingfield wrote: > Hi guys, > I'm new to the details of deb packaging... so I may be replying to the > wrong snippets... but: > [1] http://trac.jackaudio.org/wiki/SuggestedPackagingApproach Note that this is a wiki and the suggestions come from only one person. -edrz ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging jack - details on "plan B"
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 privately So 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 like Ardour 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
Re: packaging jack - details on "plan B"
Hi Jonas, On Fri, 23 Apr 2010, Jonas Smedegaard wrote: [3] Going backwards has never been promised, though. A program compiled against 0.118.0 will work with 0.34.0. However, the use of weak symbols for new features may make this available. Isn't it exactly "going backwards" if jackd2 becomes the default and jackd1 only an optional alternative? Then applications are compiled against jackd2 and potentially using jackd1 at runtime. Is that assured to work too, or only hopefully working if weak symbols work out as planned? Jack2/Jack1 are API-synchronized. Here are the sync points that have been published: JACK1JACK2 REF --- - 0.118.0 1.9.4 [1] 0.116.2 1.9.1 [2], [3] It is reasonable to expect that a program compiled against Jack2 1.9.1 will work fine with 0.116.2. Note also that the API changes since 0.109.0 (the first stable JACK MIDI release) have been minor. (Adding weak symbols, internal changes, documentations, internal header reorg.) HTH, Gabriel [1] http://jackaudio.org/node/28 [2] http://jackaudio.org/node/23 [3] http://jackaudio.org/node/22 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging jack - details on "plan B"
On Fri, Apr 23, 2010 at 02:32:45PM -0500, Gabriel M. Beddingfield wrote: Therefore, any old program will work without recompile on a new libjack0. Jack 2 (formerly jackdmp) has also rigorously maintained binary compatability with Jack 1.[3] [...] [3] Going backwards has never been promised, though. A program compiled against 0.118.0 will work with 0.34.0. However, the use of weak symbols for new features may make this available. Isn't it exactly "going backwards" if jackd2 becomes the default and jackd1 only an optional alternative? Then applications are compiled against jackd2 and potentially using jackd1 at runtime. Is that assured to work too, or only hopefully working if weak symbols work out as planned? 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
Re: packaging jack - details on "plan B"
Hi guys, I'm new to the details of deb packaging... so I may be replying to the wrong snippets... but: 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.0 what 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. Then let's make all applications to depend on 'libjack0-0.116.0', which refers to the ABI, and provide a package 'jack-defaults', which builds a meta-package 'jackd' which depends on the distribution chosen 'default' jack implementation. I don't understand why we're emphasizing the ABI of `libjack0-0.116.0'. According to the Jack devs, a program compiled against Jack 0.34.0 (released ca. 2001) is still binary-compatible with /any/ Jack implementation (whether Jack1, Jack2, tschack, etc.) They have rigorously been maintaining this. Therefore, any old program will work without recompile on a new libjack0. Jack 2 (formerly jackdmp) has also rigorously maintained binary compatability with Jack 1.[3] Therefore, the virtual package should be `libjack0', not `libjack0-0.116.0'. See also [1] and [2]. Also, I'm sure you're on top of it, but it's important that this: $ gcc -o foo `pkg-config --cflags --libs jack` foo.cpp ...does the right thing with: $ dpkg-shlibdeps foo Thanks, Gabriel [1] http://trac.jackaudio.org/wiki/SuggestedPackagingApproach [2] http://subversion.jackaudio.org/jack/tags/RELEASE_0_118_0/README.developers [3] Going backwards has never been promised, though. A program compiled against 0.118.0 will work with 0.34.0. However, the use of weak symbols for new features may make this available. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging jack - details on "plan B"
On Fri, Apr 23, 2010 at 07:35:28AM -0400, Eric Dantan Rzewnicki wrote: On Fri, Apr 23, 2010 at 10:55:20AM +0200, Jonas Smedegaard wrote: If I get no response on this by sunday, and noone else objects, I will go ahead with my proposed plan. I've tried to follow this as closely as I can, but I am new to packaging so not qualified to discuss the specifics. However, from what I do understand I do not see a consensus, yet. Also, I would ask that we restate and clarify the proposed scheme and give upstream a chance to comment. NB: though torben is truly awesome, he is not the only upstream developer. Thanks for the response. I shall not touch the libjack packaging (even step one that I find glaring and obvious) until others have explicitly requested so and not been disputed by others on this list. - 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
Re: packaging jack - details on "plan B"
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 privately >> >>So you propose to introduce 2 virtual packages: jackd and >>libjack-0.116.0? What problem does introducing the virtual package jackd >>solve? ping? >>> 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 libjack0 >> >>Ah, 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! As indicated in the other mail, we have two objectives: a) switch the default implementation b) rearrange packaging to support switching the used implementation I think b) can and should be done independently on the choice of a), which means any change to packaging needs to work even if stick with jack1. Therefore, there is no reason to loose time with planning and starting the upcoming jackd transition. > 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. You seem to insist on deciding a) before b), while I'd rather see b) implemented before a), because a) [switching the default implementation] is technically much easier to implement than b) [packaging changes], which requires rebuilds of existing packages and therefore takes potentially a lot of time (build time, coordination with the release team, etc). > 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 think this is essential for implementing and reviewing the implementation of step b). > (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. >>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.0 >> >>what 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. Then let's make all applications to depend on 'libjack0-0.116.0', which refers to the ABI, and provide a package 'jack-defaults', which builds a meta-package 'jackd' which depends on the distribution chosen 'default' jack implementation. This is similar to the 'gcc-defaults' and 'python-defaults' packages. > 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. It depends on the package. Of course there are packages that only work with a specific libjack implementation. The most prominent example for this are the respective jack daemon packages. These packages do need a shlibs.local to override our default libjack shlibs file. This can and probably will also affect some other jack application packages. > 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. > 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 c
Re: packaging jack - details on "plan B"
On Fri, Apr 23, 2010 at 10:55:20AM +0200, Jonas Smedegaard wrote: > Hi Reinhard and others, > On Wed, Apr 21, 2010 at 02:16:36PM +0200, Jonas Smedegaard wrote: >> On Wed, Apr 21, 2010 at 12:26:41PM +0200, Reinhard Tartler wrote: >>> 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? > Ping! >>> (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? > Ping! > > If I get no response on this by sunday, and noone else objects, I will > go ahead with my proposed plan. > > Please do respond - I realy do want input on this, and may very well > have missed something obvious to oters that make the plan not work out > at all. > > Also, please do speak up if anyone feels they made earlier proposals > still valid to compare against. I sincerely apologize if missing out on > them - I lost track of it in these discussions, and did not find/take > the time to go through the whole thread to isolate them. I've tried to follow this as closely as I can, but I am new to packaging so not qualified to discuss the specifics. However, from what I do understand I do not see a consensus, yet. Also, I would ask that we restate and clarify the proposed scheme and give upstream a chance to comment. NB: though torben is truly awesome, he is not the only upstream developer. -edrz ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging jack - details on "plan B"
Hi Reinhard and others, On Wed, Apr 21, 2010 at 02:16:36PM +0200, Jonas Smedegaard wrote: On Wed, Apr 21, 2010 at 12:26:41PM +0200, Reinhard Tartler wrote: 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? Ping! (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? Ping! If I get no response on this by sunday, and noone else objects, I will go ahead with my proposed plan. Please do respond - I realy do want input on this, and may very well have missed something obvious to oters that make the plan not work out at all. Also, please do speak up if anyone feels they made earlier proposals still valid to compare against. I sincerely apologize if missing out on them - I lost track of it in these discussions, and did not find/take the time to go through the whole thread to isolate them. 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
Re: packaging jack - details on "plan B"
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 jackd1 As 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 privately So 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 libjack0 Ah, 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.0 what 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 libjack
