Hi Simon,
Simon Josefsson <[email protected]> skribis:
> Ludovic Courtès <[email protected]> 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:
modified gnu/packages/tls.scm
@@ -381,16 +381,17 @@ (define-public guile-gnutls
;; This package supersedes the Guile bindings that came with GnuTLS until
;; version 3.7.8 included.
(name "guile-gnutls")
- (version "3.7.9")
+ (version "3.7.11")
(home-page "https://gitlab.com/gnutls/guile/";)
(source (origin
(method git-fetch)
(uri (git-reference
(url home-page)
+ (recursive? #t)
(commit (string-append "v" version))))
(sha256
(base32
- "00sfpqjmd263ka51fq4xf7nvaaxyfqsr3r8fj94jgx45q6q6n6wq"))
+ "06i19a7a3w80msd15ckqwnlnq38vf2frnfk3dyk77086if89mm4a"))
(file-name (git-file-name name version))
(patches (search-patches "gnutls-cross.patch"))))
(build-system gnu-build-system)
@@ -404,7 +405,11 @@ (define-public guile-gnutls
(string-append "--with-guile-site-ccache-dir="
"$(libdir)/guile/$(GUILE_EFFECTIVE_VERSION)/site-ccache")
(string-append "--with-guile-extension-dir="
- "$(libdir)/guile/$(GUILE_EFFECTIVE_VERSION)/extensions"))))
+ "$(libdir)/guile/$(GUILE_EFFECTIVE_VERSION)/extensions"))
+ #:phases (modify-phases %standard-phases
+ (add-before 'bootstrap 'pre-bootstrap
+ (lambda _
+ (patch-shebang "autopull.sh"))))))
(native-inputs
(list autoconf
automake
@@ -412,6 +417,7 @@ (define-public guile-gnutls
pkg-config
texinfo
gnutls ;XXX: 'guile-snarf' invokes the native 'cpp'
+ (@ (gnu packages version-control) git-minimal)
guile-3.0))
(inputs
(list gnutls-latest
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---
_______________________________________________
Gnutls-help mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnutls-help
