Hi Bruno, Bruno Haible <br...@clisp.org> writes:
> Maxim Cournoyer wrote: > >> There's no /bin/sh in the Guix build container, for example. > > I see. You'll have to patch *many* scripts, in many packages, to > accommodate that choice. > > And you can't upstream these changes, because the difference between > build-aux/git-version-gen ... > and > sh build-aux/git-version-gen ... > is that the latter will break when 'git-version-gen' is ever changed > from a shell script to, say, a Python script, a Guile script, or an > executable. Fair enough. I think we can keep these changes local to the Guix package of gnulib for the time being, it's small and gnulib isn't used as a package much currently (only unsyntax, a scheme implementation makes use of it in its packaged form). Most Guix packages use a custom guix origin (i.e. source/archive) that fetches gnulib at an exact commit. [...] > This is better, since it's not outdated. > > Still, you won't be able to use this gnulib checkout for all package > releases. For example, the just-released GNU gettext 0.26 or the next > GNU coreutils will need functionality from the 'master' branch of gnulib. > > Also, the comment > #:version "2025-06-30" ;date from last commit on stable-202507 branch > indicates that you wanted the last commit from the stable-202507 branch. > I updated that branch 3 days ago; see > https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib.git;a=shortlog;h=refs/heads/stable-202507 It was true when I updated the package :-). It's mostly a note to explain where the version string came from for the next person updating it. -- Thanks, Maxim
