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

[Ingo Schwarze]

Hi Werner and Paul,

Werner LEMBERG <wl@gnu.org> wrote:

> However, I have the feeling that it is moot to discuss this further.
> It seems to me part of the eternal GNU vs. BSD philosophy clash.

This appears to be independent of the BSD vs. GNU clash, which is a
question of licensing, and a question of what "free" means - the usual
problem that GPL code is not free enough for inclusion into a BSD tree,
whereas BSD code is free enough such that any GNU project can reuse it.

I think this is instead part of the question whether software should
be simple or complicated, which is orthogonal to licensing.
Both complicated BSD code and simple GNU code exist - groff is
mostly an example of the latter.

But probably you are right that i'm unlikely to convince the gnulib folks
that software ought to strive for simplicity.  So i won't answer all
the questions raised by Paul, except that i'm not sure what he measured
in OpenSSH.  I use the same approach in mandoc as they use in OpenSSH.
Mandoc used to be about 30k LOC when i last counted.  The diff from
OpenBSD to mandoc-portable currently is +212 -34 LOC.  And that is not
even all strictly for portability but includes a number of features
present in -portable that OpenBSD does not need (the .Lb macro, macOS
sandbox_init(3) support, NixOS/Guix/Homebrew Store/Cellar support,
and a memory debugging / memleak search feature).  All the same, the
difference is well below 1%.


Paul Eggert wrote on Sat, Oct 09, 2021 at 02:36:30PM -0700:

> Despite all the problems you encountered with Gnulib, I don't recall 
> seeing bug reports from you on bug-gnulib@gnu.org. That's unfortunate, 
> as unreported bugs are less likely to be fixed. At some point if you 
> have the time you might try reporting a bug or two to 
> bug-gnulib@gnu.org, and see whether the problems get fixed. Doing so 
> might suggest a better way for OpenBSD and GNU to cooperate.

I did try, for example:

  https://lists.gnu.org/archive/html/bug-gnulib/2020-10/msg00144.html

In that mail, i described one bug in detail and a number of others
more shortly (because describing bugs in detail requires effort,
and i didn't want too much effort wasted before seeing what the
reaction might be).

The outcome basically was this:

 * Regarding one bug that i reported, instead of fixing it, a note
   was added to the documentation saying something like "if you use
   gnulib, you can't rely on what the C and C++ standards say
   but have to obey our special rules instead" regarding the
   specific aspect that caused breakage.
 * All the other bugs i mentioned were ignored as far as i could
   see.

So i mostly lost interest at that point (on top of the fact that reporting
bugs in software that you consider ill-designed from the ground up is
not the most gratifying experience in the first place).

One or a few other bugs that also touched my work were reported by
Jeremy Courreges-Anglas IIRC, who did more work in that area than i did,
and something in that region definitely got improved; i'm no longer sure
about the details, i would have to look that up.

To be fair, not all experiences with reporting gnulib bugs were
negative; for example, this one was handled well, but that's
unsurprising because it was a rather simple matter:

  https://lists.gnu.org/archive/html/bug-gnulib/2014-10/msg00019.html

Yours,
  Ingo