Re: How to handle required plugins and dbus services for GNOME Programs?

[宋文武 <iyzsong@gmail.com>]

Mark H Weaver <mhw@netris.org> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@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.