Re: [proaudio] jack-audio-connection-kit

[ Thread Index | Date Index | More lists.tuxfamily.org/proaudio Archives ]


Nice. I'm still a little leery to the slotting due to collision risk,
but the virtual thing might have some advantages. If you for example
would want to have JACK1 installed you would now have to mask versions
newer than 0.121.3 (because all versioned jack ebuilds are keyworded
with ~arch) or else the JACK will be updated on emerge -u. Using
media-sound/jack1 and media-sound/jack2 would remove that problem. As
there are collisions between the two they have to block each other
until there are no conflicting files.

I think it is best if the conflicts are removed upstream so that we do
not have to do nasty unofficial patches.

The problem with the virtuals is that it might delay the stabilization
(both jack1 and jack2 have to have stable ebuilds for virtual/jack to
be allowed to be stable). However, that is not a problem until
media-libs/libffado is marked as stable (it is forcing jack to be
marked unstable).

I think the DBus can be handled by symlinking
/usr/share/dbus-1/services/org.jackaudio.service to either one of
jack1 and jack2 but I'm not completely sure.

Regards,
Karl

2013/3/24 Manuel Bärenz <manuel@xxxxxxxxxxx>:
> Hi,
>
> Well I was just starting to work on an eselect to make make all the
> symlinks work. However, I didn't give the DBus issue a thought, so maybe
> I'll report back once I've finished working on my local overlay.
>
> I wanted to have the different slots in order to test the US122L driver
> more thoroughly with JACK and cleanly separate driver problems and
> JACK1/JACK2 issues. I could just install one of the JACKs locally, but I
> thought it might be nicer to have the slot solution. However, if it's
> too messy, I'm not going to force it.
>
> About the virtual package: What advantage would that have? I admit that
> it captures the idea of JACK 1 and 2 being essentially different
> software doing roughly the same job more nicely than having different
> versions, but I can't think of any practical uses. And how would you go
> around the file conflicts? It would make it no easier, I guess.
>
> Best, Manuel
>
>



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/