Mark H Weaver <m...@netris.org> writes: > l...@gnu.org (Ludovic Courtès) writes: > >> Mark H Weaver <m...@netris.org> skribis: >> >>> A few caveats: in order for totem to work properly, you must have >>> several other packages installed in your profile. I'm not entirely sure >>> of the full set needed, but I guess it includes: >>> >>> grilo >>> grilo-plugins >>> gstreamer >>> gst-plugins-base >>> gst-plugins-good >>> dconf >>> >>> You will also need to set the GRL_PLUGIN_PATH and GST_PLUGIN_SYSTEM_PATH >>> environment variables as advised by "guix package --search-paths". >> >> I can imagine why the plugins package need to be in the profile, but I >> find the others more surprising. Do you know what happens? Are Grilo, >> GStreamer, and DConf dlopened, or is it just to get the right search >> path recommendation that they are needed? > > Actually, it turns out that 'grilo' doesn't need to be in the profile, > although if you don't have it you won't get the search path > recommendation which is crucial for Totem to work properly. According to ArchLinux, grilo-plugins is used for media discovery. Which is optional. I'm ok to add it though. > > 'gstreamer' is a propagated-input of 'gst-plugins-base', so you don't > need to explicitly install it and I'm not sure what would happen if it > were removed. It's safe to remove 'gstreamer' from inputs. > > 'dconf' apparently needs to be in the profile for both GNOME Terminal > and Totem because of the session dbus service(s) it provides. Without > it, modern GNOME programs behave quite badly. They have no way to > access or change their own configuration settings, e.g. if you go into > their preferences, you see checkboxes that do not change their state > when clicked. Yes, dconf must in profile to be known to dbus-daemon (user sesssion). It's loaded by dbus-daemon when needed.
https://developer.gnome.org/dconf/unstable/dconf-service.html > > I'm not sure how best to deal with issues like this, and also with > things like grilo-plugins and gst-plugins-* that are needed for the > proper functioning of Totem. Should we make them propagated-inputs? > > Or perhaps they should be normal inputs and we should use a wrapper to > add those directories as suffixes to GRL_PLUGIN_PATH and > GST_PLUGIN_SYSTEM_PATH automatically? Given that plugins only needed at runtime, how about make a 'raw' totem package without wrapper and propagation, and a public one wrap it with envs? Thus avoid the rebuild of the raw totem package if plugins was changed.
