[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: jack 0.94.0-2

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 ---

Attachment: signature.asc
Description: Digital signature

Reply to: