Re: man/man8/ldconfig.8: document system-wide tunables

[DJ Delorie <dj@redhat.com>]

Alejandro Colomar <alx@kernel.org> writes:
>> Add the .in macros around .EX there?
>
> But we'd need to know where to add them.  There are cases of EX/EE that
> don't need to be surrounded by '.in'

Ok, now you have a new rule that's even easier to not know about :-P

> Also, the manual pages should be readable in the form they exist in the
> repository

Not a problem here, a different indentation doesn't affect readability.

> (and match as much as possible how it will render when
> installed).

Er, close?  ;-)

Is ".in +4n" the default for .EX, unless the user changed it?  I wonder
how often that case comes up.  I wonder because I would need to review
an example of the problem to figure out how to search for it ;-)

Now I wonder if the problem case is predictable enough to have the
preprocessor *know* when .EX needs the .in +4n, and when it doesn't...

> That makes it easy to see if a change works, by running man(1) on the
> source code.

Yup, I have my own lman script that acts like man(1) but takes a
filename instead of a man page reference, finds it in the tree, and
formats it with underscores, italics, bold, *and* color!

Perhaps such a helper could be included in the git repo, just for
authors?

>> and two .EX's that do not have a closing .EE.
>> Turns out Gemini is good at perl.
>
> Please don't use LLMs for contributing to this project.

None of the patches I've sent include anything AI-generated, nor would I
attempt such a thing without disclosure, because I understand and agree
with the legal and quality issues of AI-generated output.  However, I
won't not use AI to help me understand the problems I'm trying to solve,
or optimize any diagnosing I need to do.  My time is too precious to be
stupid on purpose.

What I did was tell Gemini what I was looking for, and it wrote a perl
script faster than I could open my editor.  Cut, paste, run, throw it
away.  That was just for the statistics, of course.  If we added a
preprocessor script to the build itself, then (1) I wouldn't use AI, and
(2) it would be sed instead of perl anyway, to avoid another dependency.

Ok, now I looked for it, and we *already* use a perl script to
preprocess the files, in scripts/mk/build/pdf/book/prepare.pl.  (this
just means perl is not a new dependency, so we *could* use perl instead
of sed)

> The file "CONTRIBUTING.d/ai" contains our guidelines for their use,
> which essentially says it's not allowed.

glibc is the same way, I'm used to that.

However, glibc decided that it has no place dictating how the user uses
AI *outside* of creating the patch itself.  Yes, that includes linters,
analyzers, and perl scripts that generate statistics so I can understand
what I'm working on.

I refuse to follow any policy that tells me what my morals should be in
the privacy of my own home.