Re: documentation improvement request : mention the requirement for the /etc/shells file for proper user authentication

Simon Josefsson via Bug reports for the GNU Internet utilities <[email protected]> Sun, 09 Nov 2025 12:39:19 +0100

Newsgroups	gmane.comp.gnu.inetutils.bugs
Message-ID	<[email protected]>

Erik Auerswald <[email protected]> writes:

> I concur that "standard shell" is a bit terse, as I would not have
> understood this to mean "usually listed in /etc/shells" either.  I intend
> to push the attached patch soon, it expands point 3 of ftpd user
> authentication to:

+1

> While I can update the Texinfo documentation, and the online documentation
> is created from this, AFAIK I cannot update the online documentation.

It is usually done during the release process.  Maybe we should prepare
for a November/December release of inetutils?  There is nothing urgent
in git, I think, but a steady pace of releases seems to encourage review
and contributions.

We use www.gnu.org/s/inetutils/manual/ for distribution of manuals, but
for about a month or so www.gnu.org is completely unreachable for me (my
IP has probably been banned) and there are two things I would want to
have improved:

1) use git instead of CVS

2) find a mechanism to provide versioned manual so that

www.whatever/inetutils/manual/2.4/
www.whatever/inetutils/manual/2.5/
www.whatever/inetutils/manual/latest/

all work and points to the corresponding version.  It sometimes helps to
be able to reference documentation from earlier versions.

I'm mixed between two ways of making that happen:

A) Store generated versioned outputs in git in a sub-directory for each
release, and then normally never touch those files.

Pro:
- Stable links - unless changed in git, everything stays the same.
- Low CPU consumption

Con:
- Harder to achieve output format consistency between versions
- The output does not gain fixes from newer toolchains (texinfo etc)
- Bitrot - will we ever be able to re-generate the same outputs?

B) Write scripts that check out all releases and re-generate the
documentation tree.

Pro:
- Toolchain fixes ends up improving outputs
- We defend against bitrot in the generation process
- Easier to implement cross-version consistency

Con:
- Risk that URLs stops working if toolchain breaks URL stability
guarantees
- Waste of CPU re-generating the outputs all the time
- Risk of having spend time debugging the scripts to generate documentation

Of course, it would actually be possible to do both (regulary
re-generate documentation but store the outputs statically in a git
repo), which may mitigate some of the downsides with each approach.

We could set this up to generate static manuals on codeberg, which would
support the above more easily, and then keep uploading the latest
version using CVS to www.gnu.org.  Or just a HTTP redirect in CVS to
codeberg pages to avoid having to support both publication methods.  I
think some of the guile/guix stuff recently started to use this.

/Simon

signature.asc (application/pgp-signature, 1.2 KB)