From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: Leo Famulari <leo@famulari.name>
Cc: 53790@debbugs.gnu.org
Subject: bug#53790: Audacity has extraneous binary at directory root
Date: Sat, 05 Feb 2022 23:52:07 +0100 [thread overview]
Message-ID: <00f84dc630379d9faa930de4cf2196c840a108ee.camel@gmail.com> (raw)
In-Reply-To: <Yf7HZe/HspekeRBN@jasmine.lan>
Hi,
Am Samstag, dem 05.02.2022 um 13:52 -0500 schrieb Leo Famulari:
> On Sat, Feb 05, 2022 at 08:22:32AM +0100, Liliana Marie Prikler
> wrote:
> > Looking at the size of this thing compared to our audacity, I
> > thought to myself "hmm, that's a shell script" and sure enough
> >
> > --8<---------------cut here---------------start------------->8---
> > #!/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-
> > 5.1.8/bin/sh
> >
> > lib="${0%/*}/lib/audacity"
> > share="${0%/*}/share/audacity"
> >
> > export LD_LIBRARY_PATH="${lib}:${LD_LIBRARY_PATH}"
> > export
> > AUDACITY_MODULES_PATH="${AUDACITY_MODULES_PATH}:${lib}/modules"
> > export AUDACITY_PATH="${AUDACITY_PATH}:${share}"
> >
> > exec "${0%/*}/bin/audacity" "$@"
> > --8<---------------cut here---------------end--------------->8---
>
> Interesting...
>
> > At the time of writing none of these appear particularly needed,
> > though
> > if the time comes we might just port over the 'wrap-emacs-paths
> > phase.
>
> I figure it's there for a reason. Maybe we just need to make sure it
> ends up in 'bin/'? But, it's weird that the build scripts create
> multiple executables with the same name in these different
> directories.
I don't think it should be in bin/. Looking at the script, it appears
to be written for the install root, which... eh...
> > We can try searching for the bits in CMakeLists that install this
> > wrapper or we can simply drop the file. WDYT?
>
> I don't know... I wonder if Audacity is worse for Guix users since
> this shell script doesn't end up in $PATH.
Concerning LD_LIBRARY_PATH, that probably has no effect on Guix users.
AUDACITY_MODULES_PATH and AUDACITY_PATH could bug them, but only if run
through the store – I already added search-path specifications for
them. The question therefore really is whether to extend our wrapper or
not.
1. Cheers
next prev parent reply other threads:[~2022-02-05 22:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-04 22:03 bug#53790: Audacity has extraneous binary at directory root Leo Famulari
2022-02-05 7:22 ` Liliana Marie Prikler
2022-02-05 18:52 ` Leo Famulari
2022-02-05 22:52 ` Liliana Marie Prikler [this message]
2022-08-21 14:54 ` Liliana Marie Prikler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=00f84dc630379d9faa930de4cf2196c840a108ee.camel@gmail.com \
--to=liliana.prikler@gmail.com \
--cc=53790@debbugs.gnu.org \
--cc=leo@famulari.name \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.