On Thu, Sep 26, 2024 at 10:15:13PM +0100, Gavin Smith wrote:
> > My understanding is that if you want to install on non-standard
> > locations and want to have this non-standard location being searched for
> > before other directories, then you should put first in XDG_DATA_DIRS (or
> > XDG_CONFIG_DIRS). It should be possible to change
> > XDG_DATA_DIRS/XDG_CONFIG_DIRS as a user or for the system, but it
> > depends on the platform configuration. It seems to often be in
> > /etc/profile.d/ for system-wide early change of environment variables
> > for GNU/Linux.
>
> I don't think we should require the user (or distribution maintainer) to
> set XDG_DATA_DIRS/XDG_CONFIG_DIRS to install in non-default locations.
> Users have been able to set datadir with configure scripts for a lot
> longer than the XDG specification has existed. We should continue
> to check in datadir in line with the long-standing practice of GNU
> programs.
My point is that if $datadir/... is checked before XDG_DATA_DIRS, it
takes precedence. However, it seems to me that the intent of
XDG_DATA_DIRS is to have a configurable location for 'data' directories,
such that putting $datadir/... before is not good. (Although not for
all the files, I totally agree with what you say below).
> It may be fine to use the directories in XDG_DATA_DIRS as well as
> $datadir.
>
> It could depend on the type of file. A typical "data" file could be
> a font file (under /usr/share/fonts) that could be used by any program,
> not just those from a single package. In this view "data" is not
> a fixed, necessary part of a single program but sommething that could
> be used by multiple programs.
>
> Info files under /usr/share/info are a similar case to fonts. These may
> be accessed by programs from other packages (mainly Emacs but in theory
> any other Info reader). Although we don't at present, using XDG_DATA_DIRS
> to get directories to add to INFOPATH seems harmless.
>
> Reading texi2any init files (I can't remember if we were saying these
> were "data", "config" or both) is more problematic as these may be
> coupled to a particular version of Texinfo.
They are both "data" and "config". I do not think that we should
consider that user init files are coupled to a particular version of
Texinfo, the develpers should add code conditional to the version if
they want to support multiple versions, otherwise they should port to
the new version. This could change when the API is more stable.
However, I think that we should consider that the init file we ship are
coupled to a particular version of Texinfo.
> ${datadir}/htmlxref.cnf barely counts as a "data" file in my opinion
> as it is installed in a directory along with other files that are
> integral parts of the program (Perl modules and so on). It is
> not like we encourage anyone to add to add their own files to
> /usr/share/texinfo as they might to /usr/share/info.
But this is probably incorrect. To me htmlxref.cnf (and maybe
texinfo.dtd?) could be in a data (and same for config) shared with other
packages, and it would be ok for other implementations or htmlxref.cnf
providers to put some files there. But the other files should not.
> I am not sure if there is a better place for the files under
> /usr/share/texinfo although one suggestion is to do it the way perl
> does and use a subdirectory like /usr/share/texinfo/7.2 for integral
> package files (perl uses a directory like /usr/share/perl/5.34.0).
> Then we could have a /usr/share/texinfo/htmlxref directory for users to
> add htmlxref.cnf files.
I propose moving the files that are implementation ( dependent to
/usr/share/texi2any
(where we already search for init files) and use /usr/share/texinfo only
for files that are supposed to be non implementation dependent, such as
htmlxref.cnf.
--
Pat
