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

[Ludovic Courtès]

Federico Beffa <address@hidden> skribis:

> On Wed, Jan 7, 2015 at 9:11 PM, Ludovic Courtès <address@hidden> wrote:
>> (Sorry for the delay.)
>>
>> Federico Beffa <address@hidden> skribis:
>>
>>> On Sun, Dec 21, 2014 at 12:06 PM, Ludovic Courtès <address@hidden> wrote:
>>>> Federico Beffa <address@hidden> 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:

(It seems the MUA may have munged the patch that was supposed to be
here, see
<http://lists.gnu.org/archive/html/guix-devel/2015-01/msg00100.html>.)

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

Yes, I agree on the general principle, and that’s always what we’ve been
trying to do.

That said, this kind of patch is not very different from the automated
shebang patching that we do, IMO.

The reason I’m not thrilled by the use of ‘propagated-inputs’ here is
that that’s not what they were designed for at the beginning.

It may also lead to usability problems.  Remember that when A is a
propagated input of B, installing B in a profile also installs A in that
profile.  So, if each GTKish package propagates sound-theme-freedesktop,
then installing several such packages in the same profile is likely to
lead to collisions just because the themes differ (those collisions may
be harmless, but they will at least trigger a bunch of warnings every
time the user operates on their profile, which is not desirable.)

WDYT?

Ludo’.