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

[宋文武]

Mark H Weaver <address@hidden> writes:

> 宋文武 <address@hidden> writes:
>>> 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.
>
> Without the grl-bookmarks grilo plugin, attempts to add local video
> files to the playlist via the GUI interface silently fail.  See:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768515
>
> I ran into this problem before I packaged 'gom'.  So, although it is
> still possible to play local videos by running "totem <filename>", I
> would say that Totem malfunctions quite badly even for basic usage
> without grilo-plugins.
So grilo-plugins is really a curcial dep, thanks for explaination.
>
>>> '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.
>
> I don't understand.  Do you mean that it's safe to remove 'gstreamer'
> from the inputs of some package?  Which package?
I mean totem, sorry for the confusion.
>
>>> '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.
>
> I'm not sure it would be worth it.  Totem itself doesn't take very long
> to build.
OK.