PATCH: use a fixed jackd path for tmpdir query

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

PATCH: use a fixed jackd path for tmpdir query

Kai Vehmanen
Hi all,

I haven't followed the JACK SVN actively for a while now, but today
decided to check what's in the latest tree.

Otherwise things worked smoothly as ever, but I did notice one annoying
problem: all clients failed to start as I don't have "jackd" in my PATH.
This was related to querying the tmpdir path with "jackd -l". It wasn't
immediately obvious what could be wrong (especially as I have
JACK_NO_START_SERVER defined).

So attached is a patch against SVN-HEAD that appends 'JACK_LOCATION' to
the popen() command in question (in client.c:jack_get_tmpdir()). This
seems consistent with other code in libjack that tries to run 'jackd',
e.g. client.c:_start_server(). Of course, if someone has jackd installed
somewhere else, but not in PATH, my patch will break their setup.

--
  links, my public keys, etc at http://eca.cx/kv
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

patch-jack-kvehmanen-use-fixed-jackd-for-tmpdir-20070813.txt (886 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: use a fixed jackd path for tmpdir query

Jack O'Quin
On 8/13/07, Kai Vehmanen <[hidden email]> wrote:

> Hi all,
>
> I haven't followed the JACK SVN actively for a while now, but today
> decided to check what's in the latest tree.
>
> Otherwise things worked smoothly as ever, but I did notice one annoying
> problem: all clients failed to start as I don't have "jackd" in my PATH.
> This was related to querying the tmpdir path with "jackd -l". It wasn't
> immediately obvious what could be wrong (especially as I have
> JACK_NO_START_SERVER defined).

Sorry that bit you, Kai.

This change was part of an effort to make jackd and libjack
more "location independent".  We would like to be able to
determine the location of the tmpdir by querying the current
jackd instead of compiling it in.  This is intended to help
JACK tolerate multiple installs better.

I don't see any reasonable way to do that without requiring
people to include jackd in their path.

The implementation is yet incomplete.  As you noticed,
_start_server() in libjack still uses the compiled-in
JACK_LOCATION, and it should not.
--
 joq

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: use a fixed jackd path for tmpdir query

Kai Vehmanen
Hi,

On Mon, 13 Aug 2007, Jack O'Quin wrote:

>> Otherwise things worked smoothly as ever, but I did notice one annoying
>> problem: all clients failed to start as I don't have "jackd" in my PATH.
>
> Sorry that bit you, Kai.
>
> This change was part of an effort to make jackd and libjack
> more "location independent".  We would like to be able to
> determine the location of the tmpdir by querying the current
> jackd instead of compiling it in.  This is intended to help
> JACK tolerate multiple installs better.
[...]
> I don't see any reasonable way to do that without requiring
> people to include jackd in their path.

ok, no problem, I'm willing to stand some migration pains for better
multiple JACK installs support. ;)

But, but, having jackd in PATH as the only option seems a bit too limiting
(and clumsy to use when you have multiple jackd's installed, possible
multiple versions in directories listed in PATH). For instance on my
machine, I have a standard Debian installation of JACK plus various apps
using it, but I also maintain a separate installation of JACK+apps under a
custom prefix. The Debian 'jackd' is of course always in PATH as the
binary is under /usr/bin.

So how about if we support the sort-of-standard practise of looking up the
contents of 'BINARY' ('JACKD' in this case) enviroment variable, and if
found, run that instead of 'jackd' and rely on PATH to be correct? This is
used succesfully by many tools to select which binary to run.

For instance, the above works nicely on my 'standard-debian + custom
JACK-tree' system. When I set JACKD, I can be sure the correct binary will
be used.

--
  links, my public keys, etc at http://eca.cx/kv

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: use a fixed jackd path for tmpdir query

Jack O'Quin
On 8/13/07, Kai Vehmanen <[hidden email]> wrote:

> Hi,
>
> On Mon, 13 Aug 2007, Jack O'Quin wrote:
>
> >> Otherwise things worked smoothly as ever, but I did notice one annoying
> >> problem: all clients failed to start as I don't have "jackd" in my PATH.
> >
> > Sorry that bit you, Kai.
> >
> > This change was part of an effort to make jackd and libjack
> > more "location independent".  We would like to be able to
> > determine the location of the tmpdir by querying the current
> > jackd instead of compiling it in.  This is intended to help
> > JACK tolerate multiple installs better.
> [...]
> > I don't see any reasonable way to do that without requiring
> > people to include jackd in their path.
>
> ok, no problem, I'm willing to stand some migration pains for better
> multiple JACK installs support. ;)
>
> But, but, having jackd in PATH as the only option seems a bit too limiting
> (and clumsy to use when you have multiple jackd's installed, possible
> multiple versions in directories listed in PATH). For instance on my
> machine, I have a standard Debian installation of JACK plus various apps
> using it, but I also maintain a separate installation of JACK+apps under a
> custom prefix. The Debian 'jackd' is of course always in PATH as the
> binary is under /usr/bin.
>
> So how about if we support the sort-of-standard practise of looking up the
> contents of 'BINARY' ('JACKD' in this case) enviroment variable, and if
> found, run that instead of 'jackd' and rely on PATH to be correct? This is
> used succesfully by many tools to select which binary to run.
>
> For instance, the above works nicely on my 'standard-debian + custom
> JACK-tree' system. When I set JACKD, I can be sure the correct binary will
> be used.

I suppose we could use an environment variable to override
the $PATH lookup. I don't think anyone had suggested that
before.

You are probably doing more sophisticated things than
the problem we were trying to solve: people with a binary
JACK package installed who build and install a newer release
from source.  That bites people all the time, and we would
like to reduce the number of questions and complaints..
--
 joq

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: use a fixed jackd path for tmpdir query

Kai Vehmanen
Hi,

On Mon, 13 Aug 2007, Jack O'Quin wrote:

> I suppose we could use an environment variable to override
> the $PATH lookup. I don't think anyone had suggested that
> before.

ok, attached is an updated patch that adds getenv() lookup for $JACKD and
updates the jackd.1 man page.

> You are probably doing more sophisticated things than
> the problem we were trying to solve: people with a binary
> JACK package installed who build and install a newer release
> from source.  That bites people all the time, and we would

Right. PATH lookup might indeed be the only sane way to catch these cases
where user has overwritten a JACK installation with a self-built one.

--
  links, my public keys, etc at http://eca.cx/kv
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

patch-jack-kvehmanen-add-jackd-env-variable-20070814.txt (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: use a fixed jackd path for tmpdir query

Jack O'Quin
On 8/14/07, Kai Vehmanen <[hidden email]> wrote:

> Hi,
>
> On Mon, 13 Aug 2007, Jack O'Quin wrote:
>
> > I suppose we could use an environment variable to override
> > the $PATH lookup. I don't think anyone had suggested that
> > before.
>
> ok, attached is an updated patch that adds getenv() lookup for $JACKD and
> updates the jackd.1 man page.
>
> > You are probably doing more sophisticated things than
> > the problem we were trying to solve: people with a binary
> > JACK package installed who build and install a newer release
> > from source.  That bites people all the time, and we would
>
> Right. PATH lookup might indeed be the only sane way to catch these cases
> where user has overwritten a JACK installation with a self-built one.

Thanks for the patch, Kai.

Two suggestions:

 * The env variable name could be somewhat longer,
   maybe something like JACK_SERVER_PATH.

 * _start_server() should use the same env variable
   (and not use JACK_LOCATION).
--
 joq

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: use a fixed jackd path for tmpdir query

Kai Vehmanen
Hi,

On Tue, 14 Aug 2007, Jack O'Quin wrote:

[addition of $JACKD environment variable]
> * The env variable name could be somewhat longer,
>   maybe something like JACK_SERVER_PATH.

hmm, I kind of prefer the practice that variable name is upper case but
otherwise equal to the binary name. This is used in autotool generated
makefiles, and in many other applications.

> * _start_server() should use the same env variable
>   (and not use JACK_LOCATION).

Or maybe it should be: 1) check for $JACKD, 2) use JACK_LOCATION...?
Let's say a client is linked against /usr/local/lib/libjack.so. If we are
to launch a jackd instance, it's highly likely that the server in
/usr/local/bin/jackd is the one that will work against the version of
libjack.so we are using. Using $PATH to pick the jackd to launch seems
like a bad policy.

In the "tmpdir query" case the situation is a bit different as we are
trying to guess which 'jackd' binary is currently running (vs guessing
which jackd to start). In this case most likely case is the 'jackd' that
is in $PATH.

To be really robust, we'd need to start versioning the jackd binaries with
the jackd-libjack protocol version (with a libtool style version
modification policy to enable jackd to implement multiple protocol
versions). Unversioned "jackd" would be a symlink to the default version
to use (e.g. similarly as multiple automake versions are installed). But,
but, this probably is too complicated and would cause too much pain for
the package maintainers.

PS I don't have SVN commit access, so if any of these patches are ok,
    someone please commit them.

--
  links, my public keys, etc at http://eca.cx/kv

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: use a fixed jackd path for tmpdir query

Jack O'Quin
On 8/17/07, Kai Vehmanen <[hidden email]> wrote:

> Hi,
>
> On Tue, 14 Aug 2007, Jack O'Quin wrote:
>
> [addition of $JACKD environment variable]
> > * The env variable name could be somewhat longer,
> >   maybe something like JACK_SERVER_PATH.
>
> hmm, I kind of prefer the practice that variable name is upper case but
> otherwise equal to the binary name. This is used in autotool generated
> makefiles, and in many other applications.

That's fine with me.  The other was just a suggestion.

> > * _start_server() should use the same env variable
> >   (and not use JACK_LOCATION).
>
> Or maybe it should be: 1) check for $JACKD, 2) use JACK_LOCATION...?
> Let's say a client is linked against /usr/local/lib/libjack.so. If we are
> to launch a jackd instance, it's highly likely that the server in
> /usr/local/bin/jackd is the one that will work against the version of
> libjack.so we are using. Using $PATH to pick the jackd to launch seems
> like a bad policy.
>
> In the "tmpdir query" case the situation is a bit different as we are
> trying to guess which 'jackd' binary is currently running (vs guessing
> which jackd to start). In this case most likely case is the 'jackd' that
> is in $PATH.

You may be right.  I was looking at it differently: in both cases,
we want to resolve to whatever jackd is running or would be
running if started via _start_server() so we can use the correct
tmpdir location for that.

Paul wrote the code, so maybe he has something slightly
different in mind.  I have had no time to work on JACK at all
this year.  Perhaps he will explain the details.

> To be really robust, we'd need to start versioning the jackd binaries with
> the jackd-libjack protocol version (with a libtool style version
> modification policy to enable jackd to implement multiple protocol
> versions). Unversioned "jackd" would be a symlink to the default version
> to use (e.g. similarly as multiple automake versions are installed). But,
> but, this probably is too complicated and would cause too much pain for
> the package maintainers.

An interesting idea, but I agree that it would make packaging
rather complex.  The main goal was to make different versions
at least communicate with each other.  Then the run-time protocol
version check could catch any compatibility problems.  Since
the protocol version changes so seldom, we felt this would be
a useful step forward.  I don't really see how multiple clients
linked to multiple incompatible libraries can be made to work,
anyway.

> PS I don't have SVN commit access, so if any of these patches are ok,
>     someone please commit them.

I'll leave that to Paul.  He can commit or grant you SVN access.
He needs to sign off on this change, anyway.

Thanks (as always) for your help, Kai...
--
 joq

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: use a fixed jackd path for tmpdir query

Paul Davis
In reply to this post by Kai Vehmanen
On Fri, 2007-08-17 at 15:45 +0300, Kai Vehmanen wrote:

> Hi,
>
> On Tue, 14 Aug 2007, Jack O'Quin wrote:
>
> [addition of $JACKD environment variable]
> > * The env variable name could be somewhat longer,
> >   maybe something like JACK_SERVER_PATH.
>
> hmm, I kind of prefer the practice that variable name is upper case but
> otherwise equal to the binary name. This is used in autotool generated
> makefiles, and in many other applications.
>
> > * _start_server() should use the same env variable
> >   (and not use JACK_LOCATION).
>
> Or maybe it should be: 1) check for $JACKD, 2) use JACK_LOCATION...?
> Let's say a client is linked against /usr/local/lib/libjack.so.

apps on linux are not linked against specific library instances unless
the (brain-dead) person who initiated the compile forced them to be
(e.g. using -R). so no app is linked
against /path/to/some/lib/libjack.so, just libjack.so, which is
discovered dynamically at load time by the runtime linker.

> If we are
> to launch a jackd instance, it's highly likely that the server in
> /usr/local/bin/jackd is the one that will work against the version of
> libjack.so we are using. Using $PATH to pick the jackd to launch seems
> like a bad policy.

if the user compiled JACK to install into /some/directory, but hasn't
set up PATH and LD_LIBRARY_PATH to include to that (and in the correct
order), the user probably shouldn't be compiling software.

> In the "tmpdir query" case the situation is a bit different as we are
> trying to guess which 'jackd' binary is currently running (vs guessing
> which jackd to start). In this case most likely case is the 'jackd' that
> is in $PATH.

i really can't see the difference.

the whole point is that having > 1 install of JACK (or any tool that
comprises of a server process and a library) requires that you know what
you are doing. specifically, it requires that you setup PATH and
LD_LIBRARY_PATH to either include or disinclude the location of one of
the versions you want. not doing this makes it incredibly easy for any
user (even an experienced one) to trip up at some point (wrong server,
wrong library, or both).

the change in svn doesn't remove the requirement to know what you are
doing. what it does is to ensure that if you do know what you are doing,
it will probably work, whereas the old method (JACK_LOCATION) stands a
very good chance of not working.

--p





-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: use a fixed jackd path for tmpdir query

Kai Vehmanen
Hi,

On Fri, 17 Aug 2007, Paul Davis wrote:

>> Let's say a client is linked against /usr/local/lib/libjack.so.
> apps on linux are not linked against specific library instances unless
> the (brain-dead) person who initiated the compile forced them to be
> (e.g. using -R). so no app is linked

true, I was thinking of a case where each installed libjack has a unique
soname (this is the case on my machine for instance -> no LD_LIBRARY_PATH
modifications needed to support multi-installs of JACK).

> if the user compiled JACK to install into /some/directory, but hasn't
> set up PATH and LD_LIBRARY_PATH to include to that (and in the correct
> order), the user probably shouldn't be compiling software.

well, guilty as charged -- I'll be handing over my copy of gcc to the
nearest sw police office then. ;) Seriously, I've not had to modify PATH
nor LD_LIBRARY_PATH in the past to support multi-installs, so the recent
change in SVN broke my systems.

But you clearly don't think this is something you want to support. And
I'm fine with that so let's just drop the patch.

>> In the "tmpdir query" case the situation is a bit different as we are
>> trying to guess which 'jackd' binary is currently running (vs guessing
>> which jackd to start). In this case most likely case is the 'jackd' that
>> is in $PATH.
>
> i really can't see the difference.

If you are supposed to keep jackd in PATH, then there's no difference.
Even though personally I'd like to use $JACKD to specify which server to
use, I can live with $PATH as well. So case closed..

--
  links, my public keys, etc at http://eca.cx/kv

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel