Dima Psechnik wrote:
> 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
OK, now let's talk about the actual problem at hand.
I won't jump into t
In [1] we document three approaches, dependending on the package's usual
handling of imported/generated files.
Dima Pasechnik wrote:
> If a project does not use git's submodules, noone wants an extra
> complexity of submodules to be added to the build system just due to
> the need for gnulib.
Sur
Hi Dima,
In your messages, there are several topics, which I'll reply to separately.
Focusing on one topic means to simplify the discussion.
> regular releases are badly needed.
You make it sound like releases are so much better than steady development.
But releases are not ideal: When there is
On Thu, Aug 25, 2022 at 11:02:59PM -0500, Paul Eggert wrote:
> On 8/25/22 18:20, dmitrii.pasech...@cs.ox.ac.uk wrote:
> >
> > There has been no official gnulib release in like 8 years...
>
> As far as I'm concerned none of the releases have been "official".
> Gnulib simply doesn't work that way.
On Thu, Aug 25, 2022 at 11:02:59PM -0500, Paul Eggert wrote:
> On 8/25/22 18:20, dmitrii.pasech...@cs.ox.ac.uk wrote:
> >
> > There has been no official gnulib release in like 8 years...
>
> As far as I'm concerned none of the releases have been "official".
> Gnulib simply doesn't work that way.
Bruno Haible writes:
> Hi,
>
> Wesley Viana wrote:
>> So I was wondering how to contribute by "packing" gnulib into a brew
>> formula.
>
> Packaging gnulib through a packaging system (such as Debian, pkg, BSD ports,
> or brew) is, in the current state of things, not desirable.
>
> Gnulib is a sou
