Hello!
[Fri, 27 Feb 2004] guenter geiger wrote:
> Taking into account that theoretically all applications that support
> jack in a given (reasonabley stable) system will support the same
> version (ABI-wise), I think we could live with ppl having to update their
> whole jack - system, not just a part.
>
> I consider it more important to not have a conflicting client-server
> protocol. See it like this:
> jackd and libjack are a pair that has to go together, its like a
> shared library split into to halfs, and only the same versions fit.
>
> It would even make sense to put them into one package. I see
> no reason to install libjack and not the corresponding deamon or vice
> versa.
>
> .. and it solves a lot of headaches for users.
>
> So I vote for linking them ...
> AFAIK recommends do not influence apt.
aptitude and dselect by default install recomended packages. I don't
know if they remove others.
> .. anyhow, I think Junichi can comment on this (to lazy to think right now
> :)
>
> Guenter
Hello!
[Sat, 28 Feb 2004] Uekawa, Junichi wrote:
> That would be an acceptable behavior only on unstable development
> systems.
>
> We'd need to fix that before we release a stable version.
>
>
> I thought there was a bug filed for this... but can't find it anymore.
> strange.
It started with a bug but we then held it between the three of us.
Discussion attached. Private mail archives are only for wheenies...
To me, the libjack-jackd API seems as least as important as the
application-libjack API. So being strict with the two is also favourable
for me.
Leaves us with the idea of supporting different libjack-jackd sets _at
the same time_ as the RM and its assistants suggested.
Ok. Noone commented on whether introduce a new virtual package "libjack"
or letting libjack's depend on a specific jackd. I think the later is
better.
Robert.
--
Schmidt's Observation:
All things being equal, a fat person uses more soap
than a thin person.
--- Begin Message ---Hello! [Fri, 16 Jan 2004] guenter geiger wrote: > Hi Robert and Junichi, > > The dependency we have currently in JACK does not take into > account that a specific version of the jack library can > only be used with the same version of the jack server. > > An example: > > The following packages are installed: > libjack0.71.2-0 > jack-rack (depending on libjack-0.71.0) > libjack0.80.0-0 > ardour (depending on libjack-0.80.0-0) > jackd (version 0.94.0) > In this setup, although it's perfectly OK for our dependency system, > jack-rack is unusable, because the corresponding jackd is missing. Sure. It has been like this ever since. The JACK_PROTOCOL_VERSION (called like this in configure.in, IIRC) defined incompatibility between libjack and jackd. Everytime it changes, compatibility between the two breaks. > One solution would be to add a dependcy > > Package: libjack0.80.0-0 > Depends: jackd (= ${Source-Version}), ${shlibs:Depends} > > Another solution could be to put this dependency in the package itself. > e.g: > Package: jack-rack > Depends: jackd (= whatever version of jack I used to compile it) > > This doesnt work though, because I won't know which version of > libjack0.80.0 is installed on the users machine (is it 0.80.0 or 0.94.0 ?) > Any thoughts ? There are two interfaces we have to take care of: a) application (compiled against libjack version A soname R) libjack (version B soname S) (we have always been only discussing this set, when we talked about binary compatibility) b) jack (version C compiled against libjack version C soname T) libjack (version C soname T) (compatibility in this set is always asured because of explicit and exact dependencies) Ensuring a) makes problems and failures in b) much more frequent (like now). Ensuring b) makes (harder to debug) problems and failures in a) more frequent. The b) binary interface changes very often. Much more than the a) interface. And the JACK development team does not have to take care of b) because they always provide a single library name and if you install a new version of JACK, you always also overwrite libjack. In your first solution, the dependency interval from libjack on jackd is defined by the above mentioned protocol version. The range is a little bit larger than an exactly equal. I think the second solution is not useful. The third solution is to loosen the criteria that make us call two versions of libjack binary incompatible (more the criteria that are imposed by the JACK development team). And the fourth solution is to provide sonames of jackd. That ensures that (libjack-0.71.2-apps + libjack0.71.2-0 + jackd0.71.2) and (libjack-0.80.0-apps + libjack0.80.0-0 + jackd0.80.0) are working independently, while not concurrently and not between the two sets. You both opposed this solution hinting to the alsa-(lib|...)-(0.4|0.5|9) case. Robert. -- ...He who laughs does not believe in what he laughs at, but neither does he hate it. Therefore, laughing at evil means not preparing oneself to combat it, and laughing at good means denying the power through which good is self-propagating. -- Umberto Eco, "The Name of the Rose"
--- End Message ---
--- Begin Message ---Hello! [Sat, 17 Jan 2004] Uekawa, Junichi wrote: > I was thinking of adding a conflicts against every possible > version of libjack (only about 5 of them so far?) > and having libjack provide a > > > Provides: jackd-interface > Conflicts: jackd-interface > > So taht only one version of libjack can be installed at the > same time. Isn't this just as good as having libjack depend on a (maybe PROTOCOL specific range) version of jackd? Why the virtual package? BTW: Packages that only might want to use a JACK interface work quite well with the current setup. They just won't find a working jackd. Can we preserve whis "feature"? Robert. -- A lot of people are afraid of heights. Not me. I'm afraid of widths. -- Steven Wright
--- End Message ---
--- Begin Message ---Hi Robert and Junichi, The dependency we have currently in JACK does not take into account that a specific version of the jack library can only be used with the same version of the jack server. An example: The following packages are installed: libjack0.71.2-0 jack-rack (depending on libjack-0.71.0) libjack0.80.0-0 ardour (depending on libjack-0.80.0-0) jackd (version 0.94.0) In this setup, although it's perfectly OK for our dependency system, jack-rack is unusable, because the corresponding jackd is missing. One solution would be to add a dependcy Package: libjack0.80.0-0 Depends: jackd (= ${Source-Version}), ${shlibs:Depends} Another solution could be to put this dependency in the package itself. e.g: Package: jack-rack Depends: jackd (= whatever version of jack I used to compile it) This doesnt work though, because I won't know which version of libjack0.80.0 is installed on the users machine (is it 0.80.0 or 0.94.0 ?) Any thoughts ? Cheers, Guenter
--- End Message ---
--- Begin Message ---Hi, > The dependency we have currently in JACK does not take into > account that a specific version of the jack library can > only be used with the same version of the jack server. Yes, I am quite aware of the problem. I was thinking of adding a conflicts against every possible version of libjack (only about 5 of them so far?) and having libjack provide a Provides: jackd-interface Conflicts: jackd-interface So taht only one version of libjack can be installed at the same time. regards, junichi.
--- End Message ---
--- Begin Message ---On Sat, 17 Jan 2004, Robert Jordens wrote: > BTW: Packages that only might want to use a JACK interface work quite > well with the current setup. They just won't find a working jackd. Can > we preserve whis "feature"? Yes, I think preserving this, but being able to assure that jack-only apps find a working jack system could be the goal. I am saying could, because I am really not sure. Thinking about explaining a user that only half of the theoretically jack-aware applications work with jack because of .... (whatever geeky explanation about protocol versions ..) makes me feel a bit uncomfortable. Anyhow, a proposed solution would be that jack-only applications depend on the exact version of jackd. If we are deciding to go this way I will put this into my jack-only packages. Guenter
--- End Message ---
signature.asc
Description: Digital signature
