Re: [PATCH 3/4] gnu: libcanberra: Add propagated-input.

[Federico Beffa <beffa@ieee.org>]

On Wed, Jan 7, 2015 at 9:11 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> (Sorry for the delay.)
>
> Federico Beffa <beffa@ieee.org> skribis:
>
>> On Sun, Dec 21, 2014 at 12:06 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> Federico Beffa <beffa@ieee.org> skribis:
>>>
>>>> I propose to make sound-theme-freedesktop a propagated input of
>>>> libcanberra. This is because, according to the XDG sound theme
>>>> specification, those event sounds should always be present and used as
>>>> fall-back in case other sounds are not present.
>>>>
>>>> http://www.freedesktop.org/wiki/Specifications/sound-theme-spec/
>>>
>>> That’s not the right fix, I think.  For instance, if Evince is installed
>>> in a profile, but libcanberra itself is not in the profile, then the
>>> sound theme is not pulled and ends up not being used.
>>>
>>> Would it be possible, instead, to patch libcanberra to refer to the
>>> sound-theme directory as its fallback?
>>
>> The location of the sound theme is specified, among other things, by
>> the variable XDG_DATA_DIRS. So, if an application makes use of the
>> glib-or-gtk-build-system and has the sounds as inputs, then it should
>> find them.  I don't think we need to patch libcanberra in any way.
>>
>> With my suggestion I was trying to avoid having to specify
>> sound-theme-freedesktop in addition to libcanberra in every gtk
>> application (as, e.g., evince).
>>
>> If we make libcanberra a propagated-input of applications like evince,
>> then they would automatically know the location of the sounds (by the
>> inheritance of propagated inputs).
>
> OK, I understand the plan.
>
> What I had in mind was to instead add sound-theme-freedesktop as an
> input to libcanberra, and to patch libcanberra along these untested
> lines:
>
>
>
> I believe this is the simplest approach, and one that is likely to
> always work.

In my opinion we should only patch software where we have no
alternative which here is not the case.

This is because a patch will not necessarily apply to future versions
of a piece of software and makes maintenance more difficult and
(requiring manual intervention) more laborious.

Regards,
Fede