Bruno Haible via Gnulib discussion list <[email protected]> writes: > Hi Simon, > >> > Now that Autoconf 2.73 has been released, it should be possible for every >> > developer to installed Autoconf 2.73 and gettext 1.0 from source, right? >> >> It is not only about developers, is it? It is also about users who >> build packages from git. > > Correct. > > On the other hand, it's only the packages that use the module > 'gettext':
If so then I see no problem, since most packages only uses the 'gettext-h' module. I wonder about the description of the 'gettext' module in that case: ,---- | Translate messages to user's native language. | | The purpose of this module is: | - So that gnulib testdirs include i18n support and thus expose possible | link errors on non-glibc platforms. We want to detect such link | errors from within gnulib and fix them by adding $(LIBINTL) to | various <program>_LDADD variables. | - To fix conflicts between older versions of 'gettextize' and the newer | versions of files found in gnulib. See | https://www.gnu.org/software/gnulib/manual/html_node/gettextize-and-autopoint.html | - As a prototype if/when we someday unify gnulib-tool, libtoolize, and | gettextize in a single tool. `---- If we require gettext 1.0, is the second bullet point still relevant? Will that conflict still happens for a gettext 1.0 user when gettext 1.1 is released and gnulib updated. >> The supported build environments for my >> projects normally include Debian stable, Ubuntu LTS, most recent Fedora, >> RHEL 9+10, Guix and sometimes macOS and Windows (through msys2). > > That's why > 1) we distribute source tarballs of all releases, that include the > 'configure' script, > 2) there are different sets of build dependencies for tarballs (typically > listed in the files INSTALL + DEPENDENCIES) and for checkouts from git > (typically listed in the file HACKING). > > IMO, it is a bad move to encourage random non-developers to use the git > checkout, as opposed to the tarball, because it leads to > - frustration on the side of that user, > - pointless support questions on the package's mailing list. I think that ship has already sailed -- I think building from git tags is expected to be a supported method, and GNU/Linux distributions are (IMO rightly) moving towards that. Yes, it may mean the user building things will need many more developer tools installed. That isn't for the inexperienced user. But it also means we shouldn't unnecessarily bump the required tools beyond versions that are feasible to install for relevant users. This is more important today than it used to be, because of the trend. Consider if autoconf 2.73 has some severe bug making it impossible (or really ugly) to install properly on a Debian stable platform. Then I don't think it is reasonable to demand autoconf 2.73 for building software. It seems bumping to autoconf 2.73 and gettext 1.0 is probably okay here -- if the only really affected packages are those relying on the 'gettext' module -- but we should be prepared to reconsider if it becomes problematic. /Simon
signature.asc
Description: PGP signature
