all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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





  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.