[gnutls-help] Guile-Gnutls bindings to separate git repo?

[Simon Josefsson]

Ludovic Courtès <ludo at gnu.org> writes:

> Hi Simon,
>
> Sorry for the long delay.
>
> Simon Josefsson <simon at josefsson.org> skribis:
>
>> I pushed out 3.7.10 to improve maintainer rules a bit.  Would you like
>> to make a 3.7.11 shortly?  To test the release process and get your
>> OpenPGP key into distributions' keyring.  I'm hoping the process is just
>> 1) clone repository, 2) ./bootstrap, 3) follow README-release.
>
> I see you went ahead with new releases, thank you!
>
> Now that Gnulib’s pulled in, building from a checkout is significantly
> more difficult; for example, the package in Guix cannot be updated as-is
> because we’d first need to download a copy of all of Gnulib (with an
> “origin”) because ./autopull.sh won’t work in the isolated, network-less
> build environment.
>
> (We could build from the source tarball, but Guix is trying to gradually
> move away from that as part of its effort on reproducible builds,
> because tarballs are in fact build products.)
>
> Since there’s little C and IMO not a strong need for a sophisticated
> release machinery, I wonder if we could avoid the dependency on Gnulib?

Sure, let's see what we can do.  Several files in the previous release
comes from gnulib too, so I don't think this is about dropping gnulib
completely, only re-arranging things to work smoother.  I'd like to
understand the problem more first, as I think there are many ways to
solve it, and this is likely to become a generic problem affecting many
projects.

I can understand that you would want to build from git instead of
tarballs.  How does the download and build process work in Guix?
Without knowing anything about the environment, I imagine there is some
part of the process that downloads the git archive from gitlab, checks
out a particular git tag and verify the PGP signature or compute a hash
checksum and compares it?  Can't that process be teached how to also
download the git submodule?

Alternatively, couldn't Guix package gnulib as a separate package
(similar to autoconf-archive or some other installed source-repository),
and we could have a build-dependency on that?  ./bootstrap.sh knows
about --gnulib-refdir and --gnulib-srcdir to use external gnulib copies.
Then you don't have to teach your download process about git submodules.

Another alternative is to drop the gnulib submodule and to check in the
files from gnulib into git.  This is essentially what 3.7.10 did, since
we copied several files from gnulib.  However then I think you'd might
as well build from tarballs, because this approach turns the git
repository into a manually maintained build artifact (built by the
maintainer by running some set of tools that may or may not be committed
to git) -- which seems even worse from a security/reproducibility point
of view than automatically generated build artifacts (tarball).

There are more options too, but I think the first approach should be to
teach your download process about git submodules, or to understand
exactly why that is a bad idea.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20221213/b352f228/attachment.sig>