inconsistency in basedir spec install in $datadir, search elsewhere

Tue Aug 27 21:48:38 UTC 2024

Hello Patrice,

I think you're misunderstanding the use of "$datadir" in that part of the spec. I do not take it to mean an actual environment variable in the environment of the installation program, but rather as a placeholder *in the spec*, representing an arbitrary directory in the path specified by $XDG_DATA_DIRS, or representing the specified default value in the event that $XDG_DATA_DIRS is unset or empty.

So yes, if the value of $XDG_DATA_DIRS observed by an installation program is used to choose installation directories, and that differs from the value of the same variable observed by the installed program at runtime, then it is possible that the program will not find its installed data files.  But that has nothing to do with an environment variable named $datadir.

More importantly, however, that's not how XDG Basedir is typically used in practice. It is more common that an environment chooses installation directories for software, data files, etc in some characteristic, systematic manner, and sets $XDG_DATA_DIRS such that programs will find their files in the chosen locations.  That is, the choice of $XDG_DATA_DIRS is normally a function of the environment's installation practices, not the other way around.

Best,

John Bollinger
________________________________
From: xdg <xdg-bounces at lists.freedesktop.org> on behalf of Patrice Dumas <pertusus at free.fr>
Sent: Tuesday, August 27, 2024 4:27 PM
To: xdg at lists.freedesktop.org <xdg at lists.freedesktop.org>
Subject: inconsistency in basedir spec install in $datadir, search elsewhere

[You don't often get email from pertusus at free.fr. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Caution: External Sender. Do not open unless you know the content is safe.

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fxdg%2F2006-March%2F006256.html&data=05%7C02%7CJohn.Bollinger%40stjude.org%7Cad6c8f2317cc47c830c408dcc6df19b6%7C22340fa892264871b677d3b3e377af72%7C0%7C0%7C638603908803675804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=F4Hg1aHX8LVdJSalBcACVZEiN3zhwKZNDprNaFsY%2B8w%3D&reserved=0<https://lists.freedesktop.org/archives/xdg/2006-March/006256.html>

This lead to the current locations specification of the menu spec:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fspecifications.freedesktop.org%2Fmenu-spec%2Flatest%2Flocations.html&data=05%7C02%7CJohn.Bollinger%40stjude.org%7Cad6c8f2317cc47c830c408dcc6df19b6%7C22340fa892264871b677d3b3e377af72%7C0%7C0%7C638603908803685682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=d5ysP37UiU17YaIU97LX%2BptwhO3d9DKPGWwbXhy1cuI%3D&reserved=0<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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fxdg%2F2004-May%2F002333.html&data=05%7C02%7CJohn.Bollinger%40stjude.org%7Cad6c8f2317cc47c830c408dcc6df19b6%7C22340fa892264871b677d3b3e377af72%7C0%7C0%7C638603908803695324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=pd5X%2BcUJLtd9X%2F2c4AfnlrP2gApnjWbvYa1nIFJcE5w%3D&reserved=0<https://lists.freedesktop.org/archives/xdg/2004-May/002333.html>

--
Pat

________________________________

Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20240827/fe4828a2/attachment-0001.htm>