Re: [bug #61315] Several groff source files don't include <config.h> first

[Ingo Schwarze]

Hi Werner,

[ I'm not Cc:ing the ticket because this is not directly related
  to the ticket, but i still want to answer your questions. ]

Werner LEMBERG wrote on Sat, Oct 09, 2021 at 04:27:23PM +0000:

>> I still think it would be better to just get rid of gnulib.

> That's a bad idea IMHO.

Yes, let's agree that we disagree about that.

There is nothing wrong with an occasional disagreement.  :-)


>> It was probably useful in the 1990ies, but nowadays operating
>> systems worth supporting are usually sufficiently POSIX-compliant
>> that providing a small number of fallback functions by hand is easy
>> without pulling in such a monstrosity.

> Have you actually looked at the gnulib repository recently?

Yes, multiple times during 2021 alone, every single time because it was
causing compatibility problems that only existed because gnulib was used.
Dozens of software packages were adversely affected, not just groff, but
groff was also adversely affected more than once.  Every single one of
these problems was hard to debug because the gnulib code is so convoluted.
I have read several files in gnulib and was usually horrified by what
i saw, for multiple reasons.

Gnulib is not a package helping portability.
It is a package *harming* portability.

> Its activity is constantly high over the last few years, which
> clearly indicates that there is a constant need of fixing

That people waste time on something neither indicates it is really
needed nor that it is done in any reasonable way.

> /enhancing various functions, including many BSD platforms.

That is one among the problems.  *Enhancing* standard system functions
is a terrible idea.  If a function is missing, fine, let's provide
a fallback implementation such that the code can be compiled and works.

But if a function exists, replacing it with something else is an outrage.
In particular since the autoconf tests inspect large numbers of totally
obscure and totally irrelevant corner cases.  A config test is *not*
supposed to be a regression suite.  Even if there really is a corner
case bug somewhere, fixing that is a job for operating system developers,
not for application software.  Replacing standard system functions just
because you personally disagree with their behaviour is nothing short
of disrespectful.

I have run into cases where grnulib replaced system functions with
insecure implementations of these functions precisely because the system
implementation purposefully extended the standard in a way that made
the function more secure, but gnulib insisted on the insecure behaviour.

For a program like groff that is mostly only used by non-privileged users
on trusted input, such episodes are merely annoying (though i wasted many
hours figuring out what was going on, and a group of fellow developers
wasted several days grand total, maybe even a week).  But i would never,
ever use gnulib for any code that i need to trust - like for code that
runs as root or in a network daemon.

> And most of those functions are POSIX ones.

Indeed.  Gnulib totally loves replacing system functions defined
by POSIX, and when you dig up the reasons, you almost always find
they are completely absurd.

When you maintain a significant amount of ported software (say, a few
thousand different packages), then the only sustainable way to cope with
the gnulib stuff is to globally switch most of it off:

https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/infrastructure/db/config.site?rev=HEAD

Yes, part of that file is intended to improve performance (because
autoconf is so slow).  But significant parts are also important because
autoconf tests misdetect stuff, and many of those are related to gnulib.

Yours,
  Ingo

>> But i realize i'm probably in the minority round here with that
>> opinion; some have also argued that groff is a GNU project and GNU
>> projects are supposed to use GNU tools no matter what, even if
>> ditching them would make life easier.

> :-)