Follow-up Comment #8, sr#110435 (group autoconf): I think this bug should NOT be fixed.
The reason is that ideally, there should be one and only one tool responsible for installing config.rpath in the developer's package when needed. It's already bad enough that three(!) tools do this: gettextize, autopoint, and gnulib-tool. This creates interdependencies between GNU gettext and GNU gnulib, that fortunately are bearable because GNU gnulib changes are effective immediately - no releases. If we were to add a fourth tool (autoreconf), we would also have interdependencies between GNU autoconf and GNU gettext. Since GNU autoconf tends to have releases quite infrequently, roughly once every 3 years on average, this would mean that some aspects of GNU gettext could be blocked for several years. (There are also already interdependencies between GNU automake and GNU gettext. We have been lucky that this affects only a warning and nothing is blocked.) It is better if this bug does not get fixed - this affects few users - than that the development of GNU gettext be partially blocked for years. The proper way to fix this would be for 'autoreconf' to invoke some program (or shell script) that GNU gettext has installed. So that GNU gettext may evolve even if there are no new GNU autoconf releases for N years. Much like bash does with the bash completions: bash does not include completion logic for a multitude of package, but rather it has a mechanism through which packages can install their completion logic. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/support/?110435> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/