guix-patches
[Top][All Lists]
Advanced

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

[bug#60358] [PATCH v2 2/2] gnu: guile-gnutls: Update to 3.7.11.


From: Simon Josefsson
Subject: [bug#60358] [PATCH v2 2/2] gnu: guile-gnutls: Update to 3.7.11.
Date: Thu, 29 Dec 2022 15:55:59 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Vivien Kraus via Guix-patches via <guix-patches@gnu.org> writes:

> Le mercredi 28 décembre 2022 à 03:20 +0100, Vivien Kraus a écrit :
>> * gnu/packages/tls.scm (guile-gnutls) [phases]: Patch-shebang
>> autopull.sh and
>> autogen.sh.
>> * gnu/packages/tls.scm (guile-gnutls) [native-inupts]: Add gnulib and
>> git.
>> ---
>>  gnu/packages/tls.scm | 37 ++++++++++++++++++++++++-------------
>>  1 file changed, 24 insertions(+), 13 deletions(-)
>
> This is not required, but it shows that the gnulib package works.

Thanks for providing an example package that would use the Guix gnulib
package!

I don't think it actually does what you would want it to do: your
resulting build of guile-gnutls will likely NOT use the exact same
version of gnulib that was used when preparing and tagging the
guile-gnutls release.  That's why this approach uses GNULIB_SRCDIR to
force a different gnulib version than the intended one.  Since gnulib
doesn't offer backwards/future compatibility, this will just cause the
guile-gnutls 3.7.11 build to break at some point, or even introduce
subtle unintended bugs, when the gnulib package is updated.

However, if the 'gnulib' package in Guix would provide a copy of the git
repository, and set GNULIB_REFDIR instead, I believe it would work as
intended: ./bootstrap will pick the gnulib commit from the local copy of
gnulib.  This should always work and is future-proof, as long as the
Guix gnulib package provides all historic gnulib git commits forever.

Taking a step back, I think it boils down to two approaches when
building projects:

1) Download git submodules when download git repository of projects that
use gnulib.  This consumes a lot of bandwidth, but will set up the
project the way most developers build the project.

2) Don't fetch the gnulib git submodule (other git submodules will
probably be required, though, depending on project) and add a dependency
to a Guix 'gnulib' package that ships the entire git repository, and
modify the ./bootstrap call to do ./bootstrap --gnulib-refdir=...'.

Approach 2) is less well tested but I think it would work, and
effectively what it achieves compared to 1) is to reduce the bandwidth
requirements and avoid a dependence on an online Savannah.  Is this
really worth the complexity?  Or is there some other advantage that I'm
missing?

Thanks for caring about how gnulib is used in projects!  It is a
complicated situation, and has tricky bill-of-material and security
consequences.

/Simon

Attachment: signature.asc
Description: PGP signature


reply via email to

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