On 2017-12-06 16:10:09 (-0800), Len Ovens wrote:
> On Wed, 6 Dec 2017, David Runge wrote:
>
> > On December 6, 2017 5:17:53 PM GMT+01:00, Christopher Arndt
> > <ch...@chrisarndt.de> wrote:
> > > Am 06.12.2017 um 15:28 schrieb David Runge:
> > > > This actively keeps programs such as cadence to be integrated into
> > > the
> > > > [community] repository in Arch, as I will not add flowcanvas back
> > >
> > > Can you elaborate on that? AFAIK cadence/catia uses PyQt to draw its
> > > canvas.
> > According to its INSTALL file [1] claudia needs ladish. a2jmidid is an
> > optional dependency to cadence.
>
> That is like saying jackd is an optional dependancy to Cadence. Unless
> things have changed, there are many debian packages that end up with a
> jackd2 dependancy and switching over to jackd1 is not trivial for many
jack{1,2} _is_ a dependency for cadence on a package and build level.
a2jmidid is a build and (packaging wise) optional dependency.Maybe I should clarify: I'm writing about requirements for packages. This is basically a packaging problem, as I have to build and provide a package in the main repositories for all build (and of course runtime) dependencies of a program. ladish and a2jmidid are runtime and/or build dependencies for cadence, which means, if I want to push cadence (and all of its parts, i.e. also claudia) to the main repositories, I have to package ladish as well (which suffers from the aforementioned problems). > people. Jackd2 also does not depend on a2jmidid, but there are some > applications that depend on jackd2 being able to access a2jmidid even if it > is not listed in the depends. If jackd1 is the goto... please make it jackd3 > and be done with it. Then depricate jackd2. Or roll the code into jackd2 as > well... I really don't care which. AFAIK, jack2 is a reimplementation, with SMP support, so they are really two different architectures, that implement the same API. tbh, I always use jack2 though... There is no way of merging the two. > In case you are wondering, installing jackd1 on a debian based machine that > already has jackd2 and other audio appliactions installed will first remove > jackd2 as well as all appliactions that depend on it and then install > jackd1. The user is left with the task of reinstalling their audio sw... if > that sw doesn't first remove jackd1 so it can drop jackd2 back in place. Is > the packaging clearly broken? Yes. Can it be fixed? Half the problem is > based on policy not code. (how long has Linux Sampler not been in debian?) That luckily is not a problem with pacman on Arch Linux. I've always found packaging in Debian (derivatives) to be too painful ;-) -- https://sleepmap.de
signature.asc
Description: PGP signature
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
