packaging tchack...

[Jonas Smedegaard]

Hi Torben (and others),

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:
>> On Sat, Apr 17, 2010 at 02:31:46PM -0400, Felipe Sateler wrote:
>> >On Sat, Apr 17, 2010 at 09:25, torbenh <torbenh at gmx.de> wrote:

>> >>its fine if the default is jack2. but please leave the door open 
>> >>for people who have problems with jack2 and are better off with 
>> >>tschack.
>> >
>> >There is additional burden to packaging several versions of jack. 
>> >Unless someone takes that burden and packages another version of 
>> >jack, there is no point in making the debian package more complex. 
>> >Are there debian packages of these other versions of jack around?
>
>tschack is based on jack1.
>in its current state it has the same set of dependencies.
>and would build fine with the exact same packaging method jack1 is 
>currently built with.

I am interested in packaging tchack.

I am quite busy this week, however, so if someone could please file an 
ITP for it, on behalf of this team, then that would speed up things a 
bit.


>i might add the soundcard allocation in the future. (which adds dbus 
>dependency) but i am not completely sure if i want to do that, since it 
>could also be done using scripts.

If you mean to say that the package maintainer can just as well 
implement dbus support through distro-local hacks, then I certainly 
recommend that you do it properly upstream, in a generic way.

If you mean that you can upstream implement it either as proper C/C++ 
code or as shell wrappers, then that's a choice you are free to make as 
upstream.  If you want dbus support to be optional, then perhaps make it 
so at build time.

If you meant something else, then please elaborate.


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100420/01756bf5/attachment-0001.pgp>