Re: [PATCH] gnu: rhythmbox: Add gst-plugins-ugly dependency.

[ludo@gnu.org (Ludovic Courtès)]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

Mark H Weaver <mhw@netris.org> 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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 521 bytes --]

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.

[-- Attachment #3: Type: text/plain, Size: 1068 bytes --]


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