a comment from MP I didn't manage to track down about the pain of traditional documentation and the lack of footnotes and the mp-wp select.

Rereading processes eventually found it and now finally bring it back to where it had been wanted: http://thetarpit.org/2020/a-journey-through-the-gales-installation-process#comment-238

(Oh hey, there's Fred Fish again.)

I better quote or that ref will get lost to the shifting sands:

This is the Tenth Edition, for GDB (GDB) Version 12.0.50.20211110-git.

Copyright (C) 1988-2021 Free Software Foundation, Inc.

This edition of the GDB manual is dedicated to the memory of Fred Fish. Fred was a long-standing contributor to GDB and to Free software in general. We will miss him.

Is this because it was started in 2020 and you're writing about it now ?

This was from August 2020, yes. As to why minimal deliberation, I don't know, perhaps we weren't communicating well at the time. Looks like that had improved since earlier in the year but still it was a bit of a sleepy & sad time with retreats back to shadows, old things, old places and old ways.

With such inefficient process, no wonder buggy code is emitted.

I'm not sure about a direct link from inefficiency to bad code. Perhaps more like both coming from a common root of irresponsibility, or of people just not being very good. And there's use of automation as a drug (suppressing pain signals).

rather than supporting all the various ways manuals and documentation has been emitted historically, convert them in HTML.

There are tools for this, might even come standard with the texinfo package; example of typical results. (Oh hey, there's Fred Fish again.) There are manpage collections also rendered online in various places so converters from that format might be usable too. Not sure to what degree these produce *maintainable* output for doing a full one-time conversion as opposed to just being an output stage in a pipeline that maintains the original source format.

djb also went this way - observing the party was moving to the web - which is why there are no man pages in daemontools or djbdns though there are for the earlier qmail.

a comment from MP I didn't manage to track down about the pain of traditional documentation and the lack of footnotes and the mp-wp select.

I distinctly remember this and also sadly can't find it in the logs, in Fixpoint comments or in googling a couple other blogs.

MP-WP conversion might be a bit more involved than mere HTML conversion. And traditional documentation does have some nice properties that I'd really not want to lose, that might take some thinking. Like how it comes standard with the code (or in some separate file but in any case easy to grab in full), can be maintained in lockstep with the code, and is readily indexed and navigable on the target system, in text mode, in a revision that matches the installed code. (Incidentally Oracle's let these rot regarding the MySQL reference manual - the sources and build tools for current versions are not published that I could find.)

I went with version 7.12.1 with minimal deliberation and for reasons I can't recall;

Is this because it was started in 2020 and you're writing about it now ?

The larger long-term consideration, I figure, will be picking a version close enough to our chosen GCC and Binutils that they can be re-integrated back into a unified tree, deduplicating their not insubstantial shared components.

Alright. That Sokolov article was a trip. With such inefficient process, not wonder buggy code is emitted.

Either that or a decision to go for HTML conversion or some such.

I think this is the smarter long-term play, i.e. rather than supporting all the various was manuals and documentation has been emitted historically, convert them in HTML. This brings to mind a comment from MP I didn't manage to track down about the pain of traditional documentation and the lack of footnotes and the mp-wp select.

Thanks for explaining the current process to replace pieces in the base system in footnote iii.

since MySQL's setting _GNU_SOURCE in the first place was based on an assumption that Linux means Glibc and I didn't know what else might be broken in the same vein, I thought it best to cut to the root or at least set things on firmer ground by removing the _GNU_SOURCE definitions

Alright, makes sense to me.