Hello,
The basedir-spec currently says, in section 4:
"... $XDG_DATA_DIRS/subdir/filename ... implies that:
- Such file should be installed to $datadir/subdir/filename with
$datadir defaulting to /usr/share."
Right after, a search for the file is specified as:
- Lookups of the data file should search for ./subdir/filename relative
to all base directories specified by $XDG_DATA_HOME and $XDG_DATA_DIRS. If
an environment variable is either not set or empty, its default value
as defined by this specification should be used instead.
the last part, for $XDG_DATA_DIRS, refers to section 3:
If $XDG_DATA_DIRS is either not set or empty, a value equal
to /usr/local/share/:/usr/share/ should be used.
As a consequence, if
- $XDG_DATA_DIRS is set
and $datadir is not in $XDG_DATA_DIRS
- or $XDG_DATA_DIRS is unset
and $datadir is not /usr/local/share/
nor /usr/share/
a search for the file installed in the specified $datadir directory will
necessarily fail.
I find that difference between the datadir specified for the installation
and the directories used for the search strikingly weird.
I think that some explanation of when and how the discrepancy is
supposed to be resolved would be very useful or even needed. For
example for people in charge of both implementing the installation of
resources for a software and implementing the XDG Base Directory
Specification. Also for programs setting $XDG_DATA_DIRS and installing
resources. When I read the specification, it appeared to me to be
internally inconsistent in situations that do appear plausible, which is
always bad for a specification, in my opinion.
The explanation needs not be complex, but it should at least be
acknowledged that there is a discrepancy, if only to say that it is not
the responsibility of the specification to resolve the discrepancy. Here
is an example of wording that could follow immediately the explanation
of the search path if this option is preferred:
If $datadir is not in $XDG_DATA_DIRS, or $XDG_DATA_DIRS is unset and
$datadir is not /usr/local/share/ nor /usr/share/, the file cannot be
found according to the specification. How this situation is resolved
is not in the scope of the specification.
It would be even more helpful to have some ideas on what would follow
the spirit of the specification and could be done to make the searches
successful, such as:
If $datadir is not in $XDG_DATA_DIRS, or $XDG_DATA_DIRS is unset and
$datadir is not /usr/local/share/ nor /usr/share/, the file cannot be
found according to the specification. This could be resolved in
different ways that are outside of the scope of the specification. For
example by a modification of $XDG_DATA_DIRS to include $datadir, by
making sure that $XDG_DATA_DIRS includes the /usr/local/share/ and/or
/usr/share/ directories and setting $datadir to one of those
directories, or by adding directories to the lookup, one corresponding
to $datadir in addition to the locations specified above.
Many other options are possible, but leaving the specification as is
looks wrong to me.
The same applies to $XDG_CONFIG_DIRS and $sysconfdir.
Here is an example I found where the discrepancy was solved, as least
partly, that could give ideas on the type of what could be said, that
has the advantage of being in another XDG specification as we could
imagine that the specifications are consistent. When an issue about
installing in $XDG_DATA_DIRS was raised for the menu spec, it was changed
to specify/recommend specific datadir/sysconfdir values (if I understood
well):
https://lists.freedesktop.org/archives/xdg/2006-March/006256.html
This lead to the current locations specification of the menu spec:
https://specifications.freedesktop.org/menu-spec/latest/locations.html
You can see there that a datadir equal to /usr/share or /usr/local/share
are recommended, corresponding exactly to the $XDG_DATA_DIRS defaults
and similar for sysconfdir. This proposal therefore solves the issue when
$XDG_DATA_DIRS is unset, by recommending only specific values for
datadir instead of leaving that value unspecified as in the XDG Base
Directory Specification (it does not solve the discrepancy generally,
but at least solve the most blatantly weird situation).
I have found a thread which raised a very similar or even exactly the
same issue (my description at the beginning is loosely based on Peter
Laszlo mail), although with a different objective:
https://lists.freedesktop.org/archives/xdg/2004-May/002333.html
--
Pat
