Closed Audacious-Bot closed 6 months ago
Original Redmine Comment Author Name: John Lindgren Original Date: 2021-08-27T22:33:27Z
Not a bug. Audacious and Audacious Plugins need to be installed under the same prefix.
We don't support stow specifically (I had never heard of it until now), but perhaps it would be best to make a single stow package containing both Audacious and Audacious Plugins?
Original Redmine Comment Author Name: Thomas Zajic Original Date: 2021-08-28T07:05:09Z
John Lindgren wrote:
Not a bug. Audacious and Audacious Plugins need to be installed under the same prefix. We don't support stow specifically (I had never heard of it until now), but perhaps it would be best to make a single stow package containing both Audacious and Audacious Plugins?
Nevermind, no problem. I'll keep it around as a local patch for personal use, then. :-)
Using one common stow dir would work as well, yes, as long as the two packages always come in matched pairs. If/when they start diverging (ie. @audacious-plugins-4.1.1@ gets released because of a bug fix, while @audcaious-4.1@ stays the same), then sorting stuff out manually becomes cumbersome. And this is exactly where tools like @stow@ or @graft@ shine.
Would you reconsider accepting the patch if I made it more elaborate, like adding an @--enable-stow-hack@ option to the @autotools/configure@ and @meson/ninja@ setup (which would default to "no", of course), and then wrapping the actual patch in a corresponding @#ifdef/#else/#endif@ in the source code? I'm not sure whether that would actually be worth the effort (as opposed to keeping a local one-liner @diff@ around), but it could be a fun little mini-side-project if time permits. But if you say no either way, that would be okay as well. ;-)
Author Name: Thomas Zajic Original Redmine Issue: https://redmine.audacious-media-player.org/issues/1123 Original Date: 2021-08-16
When Audacious is installed via "GNU @stow@":https://www.gnu.org/software/stow/ (or the similar @graft@ utility), it refuses to start because it can't find its modules (which are typically installed in a different stow directory when using these utilities). The attached trivial patch fixes this issue by falling back to @set_default_paths()@ in @static void set_install_paths()@ (@src/libaudcore/runtime.cc@, lines 205ff) if the detected @get_path_to_self()@ contains @"/stow/"@ or @"/graft/"@.