Hi Bruno, Thanks for your reply.
Bruno Haible <br...@clisp.org> writes: > Hi Maxim, > >> Some distributions such as GNU Guix include in their package for >> gnulib a 'gnulib-tool' command under their $bindir >> prefix (e.g. '/bin') for users to use, along the unmodified full >> sources. > > And this package is [1] from 2024-05-30 and therefore unsupported. > > The Gnulib manual states very early ([2] section 1.3 "Keeping Up-to-date") > that the best way to use Gnulib is from its git repository. > > It also states ([2] section 1.6.1 "Stable Branches") that the only > supported stable branches are those that start at 2025-01 and 2025-07. > No bug fixes are being done on Gnulib versions older than 2024-12-31. Thanks for bringing this to my attention, I've updated it [0]. [0] https://codeberg.org/guix/guix/commit/4962cb0ad24b4425ea77823c35eb88aaadaf790b >> The idea is that any wrapping or distribution modifications >> for the *execution* of the script at run time is done on these >> commands, while the rest of the source should be in their >> pristine (unmodified) version. Adjust the 'gnulib-tool' discovery >> mechanism to support such installation layout. > > I don't understand what you mean by that. Are you saying that Guix has > modified gnulib-tool? If so, what are the added features or fixes? No real functional modifications, just patching of shebangs, as done automatically in the patch-shebangs phase that happens after install phase: --8<---------------cut here---------------start------------->8--- phase `install' succeeded after 6.0 seconds starting phase `patch-shebangs' patch-shebang: /gnu/store/dw6qybgypz10rrsl3bwm1kxb77kl9sm1-gnulib-2025-06-30-1.9297749/bin/gnulib-tool: changing `/bin/sh' to `/gnu/store/nnx8iifrj6jfih4sivivq17cf65aa968-bash-minimal-5.2.37/bin/sh' patch-shebang: /gnu/store/dw6qybgypz10rrsl3bwm1kxb77kl9sm1-gnulib-2025-06-30-1.9297749/bin/gnulib-tool.py: changing `/bin/sh' to `/gnu/store/nnx8iifrj6jfih4sivivq17cf65aa968-bash-minimal-5.2.37/bin/sh' patch-shebang: /gnu/store/dw6qybgypz10rrsl3bwm1kxb77kl9sm1-gnulib-2025-06-30-1.9297749/bin/gnulib-tool.sh: changing `/bin/sh' to `/gnu/store/nnx8iifrj6jfih4sivivq17cf65aa968-bash-minimal-5.2.37/bin/sh' phase `patch-shebangs' succeeded after 0.0 seconds --8<---------------cut here---------------end--------------->8--- >> * build-aux/bootstrap (autogen) <gnulib_tool>: Prefer to use from >> PATH, else from $GNULIB_SRCDIR/../../bin/gnulib-tool, else from >> $GNULIB_SRCDIR/gnulib-tool. > > No, we don't want that. The purpose of the environment variable > GNULIB_SRCDIR is to let the developer control directly which > gnulib checkout to use. We do *not* want a gnulib checkout that > is unsupported to take priority over that. It stills behaves that way, except for the bin/gnulib-tool which is installed with the package, if it's found on PATH. This allows in Guix to use gnulib-tool with the patched shebangs instead of using /bin/sh, which would be a) more fragile (may pick a different shell implementation than was tested it) or b) absent (if you were to e.g. run the script in a guix build container, where there's no /bin FHS directory at all). >> Invoke script via 'sh' from PATH, for portability. >> ... >> (func_version): Explicitly invoke git-version-gen via 'sh' to avoid >> relying on the exact location of 'sh' hard-coded in the script >> shebang. > > Why would that be needed? Guix 1.4, which is the newest release [3], > has /bin/sh (necessary for shell scripts) and /usr/bin/env (necessary > for scripts in other scripting languages, from clisp to perl). > > Android which doesn't have /bin/sh is not a supported development > environment for using gnulib-tool; we support it only as a target platform. > That is, a developer is supposed to create their tarball on a GNU system, > before building it on Android. There's no /bin/sh in the Guix build container, for example. -- Thanks, Maxim
