Re: Creating a formula for Homebrew

[dmitrii . pasechnik]

Hi Paul,
On Thu, Aug 25, 2022 at 02:35:26PM -0500, Paul Eggert wrote:
> On 8/25/22 09:53, dmitrii.pasechnik@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

> 
>