[Top][All Lists]

[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.


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 ]
   # Load Bash-specific initialization code.
This is inelegant, but better than broken software IMO.


> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]