Re: Texinfo 7.0 changed the name of HTML output directory

[Patrice Dumas]

On Mon, Aug 26, 2024 at 02:29:10PM +0300, Eli Zaretskii wrote:
> > Date: Mon, 26 Aug 2024 09:02:37 +0200
> > From: Patrice Dumas <pertusus@free.fr>
> > 
> > On Sun, Aug 25, 2024 at 06:57:42PM +0100, Gavin Smith wrote:
> > > On Sun, Aug 25, 2024 at 02:15:17PM +0200, Patrice Dumas wrote:
> > > > On Sun, Aug 25, 2024 at 11:32:01AM +0100, Gavin Smith wrote:
> > > > > We should at least support the "XDG Base Directory Specification".
> > 
> > I see three possibilities for the locations that do not already follow
> > the XDG Specification, locations like /etc/texinfo or /etc/texi2any, and
> > locations like $HOME/.texinfo or $HOME/.texi2any
> > 
> > 1) remove them as possibilities completly and mark in the documentation
> >   that the new directory have to be used
> > 2) keep them as possibilities but mark them deprecated in the
> >   documentation, add warnings in the code and keep them about 5 years
> > 3) keep them and maintain them
> > 
> > I would lean towards 2), otherwise there would be too many directories
> > searched for.
> > 
> > Opinions?
> 
> XDG is supported only on some systems.  For example, MS-Windows
> doesn't support it, and I'm not sure about macOS.

I have not seen anything platform specific in the specification, as far
as I can tell (except for the path separator), no more than what we
currently do.

> So my suggestion is look for the files in their traditional places,
> and failing that to fall back on XDG-mandated locations (with suitable
> defaults as defined by XDG, if the relevant environment variables are
> not set).

But that means that you support forever two locations, the traditional
places, and the XDG-mandated locations if variables are not set.  I
wanted to support only one, the XDG-mandated locations if variables are
not set and deprecate the traditional locations (and use the XDG
environment variables if set, but there is no trade-off with that case).

> This is what Emacs does, and we have yet to hear a single
> complaint.  We found this to be the best alternative in terms of
> backward compatibility: it allows users smooth migration to
> XDG-compliant configuration if and when they so desire.

It's no wonder that no one complain, all the added complexity is on you. 
I wanted to avoid that.

> (Btw, AFAIK XDG directories can be ephemeral, and the environment
> variables can be removed when the user logs off.  This should be kept
> in mind when designing the support for XDG.)

Ok.

-- 
Pat