[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] gnu: rhythmbox: Add gst-plugins-ugly dependency.
From: |
Ludovic Courtès |
Subject: |
Re: [PATCH] gnu: rhythmbox: Add gst-plugins-ugly dependency. |
Date: |
Tue, 25 Aug 2015 17:19:43 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Mark H Weaver <address@hidden> skribis:
> I don't think we should apply this patch. Instead, please set
> GST_PLUGIN_SYSTEM_PATH to ~/.guix-profile/lib/gstreamer-1.0 and then
> all gstreamer plugins installed in your profile should be available
> to programs based on gstreamer. Works for me with totem, anyway.
>
> Note that we have a 'native-search-paths' specification on the
> 'gstreamer' package, so if you install that package in your profile, it
> should remind you to set GST_PLUGIN_SYSTEM_PATH. Unfortunately, this is
> not very satisfactory because there's usually no reason to install
> gstreamer in your profile.
Right.
As an interim solution, I would suggest this:
diff --git a/gnu/system.scm b/gnu/system.scm
index ea6e9c1..2c1387e 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -511,6 +511,9 @@ export DBUS_FATAL_WARNINGS=0
# Allow Aspell to find dictionaries installed in the user profile.
export ASPELL_CONF=\"dict-dir $HOME/.guix-profile/lib/aspell\"
+# Allow GStreamer-based applications to find plugins.
+export GST_PLUGIN_PATH=\"$HOME/.guix-profile/lib/gstreamer-1.0\"
+
if [ -n \"$BASH_VERSION\" -a -f /etc/bashrc ]
then
# Load Bash-specific initialization code.
This is inelegant, but better than broken software IMO.
WDYT?
> It would be good to find a better solution to this more general problem.
> Ideally, it would be good to remind the user about 'native-search-paths'
> for all *run-time* dependencies of the packages in the user's profile.
> Things get messy in a different way when your packages are split between
> your user profile and the system profile. I'm not sure yet how to solve
> the more general problem.
That’s something we might be able to do, indeed, and it sounds good.
Technically, populating <manifest-entry>’s ‘search-paths’ fields with
search paths of the *run-time* dependencies may be difficult: We could
get the information on run-time deps in the derivation that builds the
manifest (via #:references-graph), but then that derivation would need
to know all the possible search paths (that is, those of the build-time
dependencies) so that it can select the subset of search paths
corresponding to run-time dependencies.
Needs more thought.
Thanks,
Ludo’.