Vivien Kraus <vivien@planete-kraus.eu> writes:

> Le mercredi 28 décembre 2022 à 03:20 +0100, Vivien Kraus a écrit :
>> @@ -412,7 +421,13 @@ (define-public guile-gnutls
>>             pkg-config
>>             texinfo
>>             gnutls                 ;XXX: 'guile-snarf' invokes the
>> native 'cpp'
>> -           guile-3.0))
>> +           guile-3.0
>> +           (gnulib-checkout
>> +            "2022-12-06"
>> +            "440b528b1d81dd31b2a2e4dde20d5c837c147811"
>> +            "15mq43abbnkbamchc9lynrvrd5ql8qacgyx2ph4kkngxf1bz3pqy")
>> +           git ; gnulib requires git even if nothing is downloaded.
>> +           ))
>>      (inputs
>>       (list gnutls-latest
>>             guile-3.0))
>
> I can still pick an exact commit of gnulib (I was not aware that it
> would be required, I thought the most common idea was "give me any
> version of gnulib later than <>"). And I don’t have to package every
> commit of gnulib, but only those that are actually used.
>
> I’m not sure guix people will be happy to have each package use a
> differently outdated version of gnulib though.

Interesting approach!  I believe this works in Guix, and is also
compatible with the way gnulib is intended to be used.

However, doesn't this lead to a gazillion variants of gnulib being
installed into /gnu/store, once all projects that use gnulib adopt this
model in Guix?  And built on the build servers, and downloaded via
substitute servers?  One gnulib for each particular commit that is used
by each respective project that rely on gnulib.  That sounds worse than
having to download copies of gnulib when building a Guix package, which
I thought was what you wanted to accomplish.

/Simon