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

[Ludovic Courtès]

Hi Simon,

Simon Josefsson <simon at josefsson.org> skribis:

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

[...]

>> 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?

Yes, we can change the origin to grab sub-modules as well:

        (origin
          (method git-fetch)
          (uri (git-reference
                (url home-page)
                (recursive? #t)  ; ← here
                (commit (string-append "v" version))))
          (sha256
           (base32
            "06i19a7a3w80msd15ckqwnlnq38vf2frnfk3dyk77086if89mm4a"))
          (file-name (git-file-name name version))
          (patches (search-patches "gnutls-cross.patch")))

As a result, the build process starts by cloning the Gnulib repository,
which is orders of magnitudes bigger than that of Guile-GnuTLS.

But that’s not enough: now ./bootstrap expects ‘git’ to be in $PATH, so
I need to add that dependency, and it wants to run ./autopull.sh, so I
need to patch its shebang, etc.; here’s the modified package:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-patch
Size: 1878 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20221220/2a51a4db/attachment.bin>
-------------- next part --------------

That’s not good enough though, because:

--8<---------------cut here---------------start------------->8---
starting phase `pre-bootstrap'
patch-shebang: autopull.sh: changing `/bin/sh' to `/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/sh'
phase `pre-bootstrap' succeeded after 0.0 seconds
starting phase `bootstrap'
running './bootstrap'
patch-shebang: ./bootstrap: changing `/bin/sh' to `/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/sh'
./bootstrap: Bootstrapping from checked-out guile-gnutls sources...
./autopull.sh: getting gnulib files...
fatal: not a git repository (or any of the parent directories): .git
./bootstrap: autopull.sh failed.
error: in phase 'bootstrap': uncaught exception:
%exception #<&invoke-error program: "./bootstrap" arguments: () exit-status: 1 term-signal: #f stop-signal: #f> 
phase `bootstrap' failed after 1.0 seconds
--8<---------------cut here---------------end--------------->8---

Taking a step back, we’re using Gnulib for these modules:

  git-version-gen
  havelib
  gitlog-to-changelog
  readme-release
  update-copyright

Does Gnulib “pay for its weight”?  In this case, I don’t think so.

In Guix, I manually copied ‘git-version-gen’ and ‘gitlog-to-changelog’
in the tree, back in the day.  The ‘bootstrap’ script does little more
than “autoreconf -vfi” (nowadays it does weird things related to i18n,
but that’s another story).  Yes, this duplicates two files and a few
lines in ‘Makefile.am’ and ‘configure.ac’, but the end result is far
more tractable IMO¹.

Mind you, this is not criticism of Gnulib in general; as you know I was
an early adopter and promoter, and it’s served us well in Guile for its
C portability helpers.  I think we have to check the cost/benefit ratio,
which has both technical and social aspects to it, and in this
particular case, I view Gnulib an unnecessary burden.

WDYT?

Ludo’.

¹ The bootstrap + Gnulib machinery in Guile-GnuTLS is almost 900 lines:

--8<---------------cut here---------------start------------->8---
$ wc -l bootstrap* cfg.mk
  214 bootstrap
   44 bootstrap.conf
  594 bootstrap-funclib.sh
   39 cfg.mk
  891 total
--8<---------------cut here---------------end--------------->8---