Hi Paul, On Thu, Aug 25, 2022 at 02:35:26PM -0500, Paul Eggert wrote: > On 8/25/22 09:53, dmitrii.pasech...@cs.ox.ac.uk wrote: > > I don't think this is how gnulib is usually used, and that's why regular > > releases are badly needed. > > It's how Gnulib developers (who do maintain other packages) usually use > Gnulib. You're welcome to use releases if you like, though it's not > recommended. If you want regular releases you can of course create them > yourselves (again, not recommended by Gnulib developers).
There has been no official gnulib release in like 8 years... > > > > > We are in fact having a fight now over whether to check in the > > iconv pieces produced by gnulib-tool into the source tree, or call > > gnulib-tool at bootstrap. > > https://trac.sagemath.org/ticket/34152 > > I haven't looked at that. However, if there's a fight, and if people > tend to want old Gnulib code even if it's buggy (so long as it's > "stable"), then you might be better off committing the iconv pieces. Some people want to follow gnulib guidelines to the letter - even though as you admit it's meant mostly for a small range of mostly FSF's projects crucially dependent on gnulib, not just for using a relatively small and stable part of gnulib. I won't be surprised if the only changes done to iconv support in gnulib over these years consisted of bumping copyright years... For 3+ years we didn't see a bug while using gettext's m4 macros needed for iconv support, thus being provided by "old" gettext packages on various Linux and BSD systems, not by gnulib directly. Yes, that's akin to using AM_ICONV directly - something that according to you only brave people do :-) https://lists.gnu.org/archive/html/autoconf/2002-09/msg00181.html The only obstacle was to get config.rpath file properly installed - a task for which we had a hack fishing it out of gettext installation and copying it into the right place, something automake isn't able to accomplish on its own (as it's not in automake's libdir). It's some kind of a weird tradition of jumping through hoops to get config.rpath, while config.guess and config.sub are provided by automake. :-) https://trac.sagemath.org/ticket/27823#comment:17 Is it an autotools bug, that config.rpath deficiency ? As to "committing iconv pieces" - it's over 100K of totally alien to the project code in this case. Why you at gnulib headquarters want large chunks of gnulib scattered accross many, many thousands of downstream git trees, I don't know. Imagine gnulib was a C macro library, for which you provided a tool to copy select sets of headers into the downstream source trees, instead of installing headers into a standard location, how would it'd been flying with downstream? Dima > >
