On Thu, Aug 29, 2024 at 09:11:20AM +0200, Patrice Dumas wrote:
> To me data vs configuration is, in general, not about the nature of the
> information, but about the intent on how a resource is modifiable and by
> whom. If the resource is considered to be a non-changeable asset, it is
> data, but the exact same file could be configuration in another place
> where it is editable. It is the established practice, in sysconfdir the
> installed or searched files are supposed to be edited, while the files
> installed in datadir are not supposed to be edited, and could be mounted
> read-only. The XDG Base Directory Specification allows this
> interpretation by not defining precisely what data and configuration is.
...
> To me it htmlxref.cnf is both "configuration", as a locally modified
> version is relevant, found in sysconfdir, and "data" as an immutable
> default file considered as data and installed by GNU Texinfo is also to
> be considered. That's what we did before and I think that it is right.
I understand the idea of files in datadir not being edited, although
I am still not really sure what the purpose of XDG_DATA_DIRS is (in
general, not just as it relates to Texinfo). According to the XDG
Specification, this is /usr/local/share:/usr/share by default, which is
where the files are installed by the package as an integral part of the
program. This corresponds to the ${datadir} of the GNU Coding Standards.
I do not understand why anyone would set XDG_DATA_DIRS.
It seems that XDG_DATA_DIRS (and XDG_CONFIG_DIRS) are already set on
my system (Linux Mint 21.2 Xfce, which is an Ubuntu derivative) when I
log in. If this is frequent, then it causes problems for people installing
to non-standard ${datadir} (and ${sysconfdir}) where files in the wrong
locations would be used if these variables take priority over compiled-in
values.
Could we consider ignoring the XDG_DATA_DIRS and XDG_CONFIG_DIRS part
of the specification? (It seems that XDG_DATA_HOME and XDG_CONFIG_HOME
are the part that people really care about.)
We could try discussing with developers of other GNU packages what
they do about these variables, and how the XDG specification works
with the GNU Coding Standards and existing practice.
