[bug#73073] [PATCH v3 2/8] gnu: gnome-recipes: Move libgd origin from phases to native-inputs.

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi,
>
> On Thu, 12 Dec 2024 at 23:18, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:
>
>>> > > +                           (file-name (git-file-name "libgd" version))
>>> >
>>> > Not sure what the state of this is here, but again noting that
>>> > "version" has no meaning in the libgd input and "checkout" would be
>>> > more honest.
>>>
>>> You’re right, though packages do have a ‘version’ field; use of
>>> ‘git-file-name’ here follows established convention in Guix.
>>
>> Does it?  Assume libfoo 3.0 and libbar 0.1.0 pull in the same libgd.
>> What happens?
>
> Not sure it really matter since it’s a fixed output.  The item reads:
>
>     /gnu/store/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-libgd-YYYY
>
> where xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx is determined by the SHA256
> checksum.  Therefore, YYYY can be anything, it does not really matter.
>
> At worse, the item is downloaded several times, say by libfoo 3.0 and
> libbar 0.1.0.
>
> All in all, I agree that the best solution here is simply:
>
>     (file-name "libgd-checkout")

Not sure I understand the full context, but it seems we're talking about
a package generator that bakes a version to some source input which is
not the version of the source itself.  Could the source/origin be
defined as a variable with the correct version and then simply provided
to the package?  It'snice for store file names to tell the real story in
general, as it makes things a bit clearer when debugging problems.

Apologies if I misunderstood something.

-- 
Thanks,
Maxim