Ludovic Courtès <[email protected]> writes: > Hi Simon, > > Sorry for the long delay. > > Simon Josefsson <[email protected]> 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
signature.asc
Description: PGP signature
_______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
