guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ludovic Courtès
Subject: Re: [PATCH 3/4] gnu: libcanberra: Add propagated-input.
Date: Sat, 10 Jan 2015 22:13:56 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

Federico Beffa <address@hidden> skribis:

> On Thu, Jan 8, 2015 at 9:39 PM, Ludovic Courtès <address@hidden> wrote:
>> That said, this kind of patch is not very different from the automated
>> shebang patching that we do, IMO.
>
> I do not see it this way because the shebang concept is fully
> standardized, while here we are patching a "random" piece of code.

Yeah, but it’s in the same “spirit”.  :-)

>> 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.)
>
> Thanks for explaining your concern. But doesn't this problem exist
> with most uses of propagated-inputs? As one example libssh2 propagates
> libgcrypt. If the user installs a different version of libgcrypt (with
> a possibly different ABI), doesn't this causes problems (required
> version not found, or worse)?

Yes, you’re right.  But the difference is that in the use case we’re
discussing here, we know it would systematically collide.

> In any case I've updated libcanberra with a patch to find the default
> sounds without the need for propagated-inputs. Differently from your
> suggested patch I'm proposing to add the default sounds store
> directory to the code dealing with XDG_DATA_DIRS. This is because
> XDG_DATA_HOME can only be a single directory and is inspected first.
> XDG_DATA_DIRS can list an arbitrary number of directories and is only
> inspected later. This is designed to allows the user to modify any
> theme at his pleasure.

Very good!  Could you add the story about XDG_DATA_DIRS
vs. XDG_DATA_HOME as a comment above the phase?

> +          (let ((sounds (string-append
> +                         (assoc-ref inputs "sound-theme-freedesktop")
> +                         "/share")))
> +            (substitute* "src/sound-theme-spec.c"
> +              (("return \"/usr/local/share:/usr/share\";")
> +               (string-append "return \"" sounds "\";\n"
> +                              "             else {\n"
> +                              "                const char *stp = \":"
> +                              sounds "\";\n"
> +                              "                size_t len =  strlen(stp) + "
> +                              "strlen(g) + 1;\n"
> +                              "                "
> +                              "char *g2 = (char*) malloc(len);\n"
> +                              "                return "
> +                              "strcat(strcpy(g2, g), stp);\n"
> +                              "        }")))))

Why not just:

  (string-append "return \"" sounds "\";")

?

Thanks,
Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]