<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style> </head> <body dir="ltr"> <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> Hello Patrice,</div> <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> I think you're misunderstanding the use of "<code>$datadir</code>" 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 <code>$XDG_DATA_DIRS</code>, or representing the specified default value in the event that <code>$XDG_DATA_DIRS</code> is unset or empty.</div> <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> So yes, if the value of <code>$XDG_DATA_DIRS</code> 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 <code>$datadir</code>.</div> <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> 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 <code>$XDG_DATA_DIRS</code> such that programs will find their files in the chosen locations. That is, the choice of <code>$XDG_DATA_DIRS</code> is normally a function of the environment's installation practices, not the other way around.</div> <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> Best,</div> <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> John Bollinger</div> <div id="appendonsend"></div> <hr style="display:inline-block;width:98%" tabindex="-1"> <div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> xdg <xdg-bounces@lists.freedesktop.org> on behalf of Patrice Dumas <pertusus@free.fr><br> <b>Sent:</b> Tuesday, August 27, 2024 4:27 PM<br> <b>To:</b> xdg@lists.freedesktop.org <xdg@lists.freedesktop.org><br> <b>Subject:</b> inconsistency in basedir spec install in $datadir, search elsewhere</font> <div> </div> </div> <div class="BodyFragment"><font size="2"><span style="font-size:11pt;"> <div class="PlainText">[You don't often get email from pertusus@free.fr. Learn why this is important at <a href="https://aka.ms/LearnAboutSenderIdentification">https://aka.ms/LearnAboutSenderIdentification</a> ]<br> <br> Caution: External Sender. Do not open unless you know the content is safe.<br> <br> <br> Hello,<br> <br> The basedir-spec currently says, in section 4:<br> <br> "... $XDG_DATA_DIRS/subdir/filename ... implies that:<br> - Such file should be installed to $datadir/subdir/filename with<br> $datadir defaulting to /usr/share."<br> <br> Right after, a search for the file is specified as:<br> <br> - Lookups of the data file should search for ./subdir/filename relative<br> to all base directories specified by $XDG_DATA_HOME and $XDG_DATA_DIRS. If<br> an environment variable is either not set or empty, its default value<br> as defined by this specification should be used instead.<br> <br> the last part, for $XDG_DATA_DIRS, refers to section 3:<br> <br> If $XDG_DATA_DIRS is either not set or empty, a value equal<br> to /usr/local/share/:/usr/share/ should be used.<br> <br> As a consequence, if<br> - $XDG_DATA_DIRS is set<br> and $datadir is not in $XDG_DATA_DIRS<br> - or $XDG_DATA_DIRS is unset<br> and $datadir is not /usr/local/share/<br> nor /usr/share/<br> a search for the file installed in the specified $datadir directory will<br> necessarily fail.<br> <br> I find that difference between the datadir specified for the installation<br> and the directories used for the search strikingly weird.<br> <br> I think that some explanation of when and how the discrepancy is<br> supposed to be resolved would be very useful or even needed. For<br> example for people in charge of both implementing the installation of<br> resources for a software and implementing the XDG Base Directory<br> Specification. Also for programs setting $XDG_DATA_DIRS and installing<br> resources. When I read the specification, it appeared to me to be<br> internally inconsistent in situations that do appear plausible, which is<br> always bad for a specification, in my opinion.<br> <br> The explanation needs not be complex, but it should at least be<br> acknowledged that there is a discrepancy, if only to say that it is not<br> the responsibility of the specification to resolve the discrepancy. Here<br> is an example of wording that could follow immediately the explanation<br> of the search path if this option is preferred:<br> <br> If $datadir is not in $XDG_DATA_DIRS, or $XDG_DATA_DIRS is unset and<br> $datadir is not /usr/local/share/ nor /usr/share/, the file cannot be<br> found according to the specification. How this situation is resolved<br> is not in the scope of the specification.<br> <br> It would be even more helpful to have some ideas on what would follow<br> the spirit of the specification and could be done to make the searches<br> successful, such as:<br> <br> If $datadir is not in $XDG_DATA_DIRS, or $XDG_DATA_DIRS is unset and<br> $datadir is not /usr/local/share/ nor /usr/share/, the file cannot be<br> found according to the specification. This could be resolved in<br> different ways that are outside of the scope of the specification. For<br> example by a modification of $XDG_DATA_DIRS to include $datadir, by<br> making sure that $XDG_DATA_DIRS includes the /usr/local/share/ and/or<br> /usr/share/ directories and setting $datadir to one of those<br> directories, or by adding directories to the lookup, one corresponding<br> to $datadir in addition to the locations specified above.<br> <br> Many other options are possible, but leaving the specification as is<br> looks wrong to me.<br> <br> The same applies to $XDG_CONFIG_DIRS and $sysconfdir.<br> <br> <br> Here is an example I found where the discrepancy was solved, as least<br> partly, that could give ideas on the type of what could be said, that<br> has the advantage of being in another XDG specification as we could<br> imagine that the specifications are consistent. When an issue about<br> installing in $XDG_DATA_DIRS was raised for the menu spec, it was changed<br> to specify/recommend specific datadir/sysconfdir values (if I understood<br> well):<br> <a href="https://lists.freedesktop.org/archives/xdg/2006-March/006256.html">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</a><br> <br> This lead to the current locations specification of the menu spec:<br> <a href="https://specifications.freedesktop.org/menu-spec/latest/locations.html">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</a><br> <br> You can see there that a datadir equal to /usr/share or /usr/local/share<br> are recommended, corresponding exactly to the $XDG_DATA_DIRS defaults<br> and similar for sysconfdir. This proposal therefore solves the issue when<br> $XDG_DATA_DIRS is unset, by recommending only specific values for<br> datadir instead of leaving that value unspecified as in the XDG Base<br> Directory Specification (it does not solve the discrepancy generally,<br> but at least solve the most blatantly weird situation).<br> <br> <br> I have found a thread which raised a very similar or even exactly the<br> same issue (my description at the beginning is loosely based on Peter<br> Laszlo mail), although with a different objective:<br> <a href="https://lists.freedesktop.org/archives/xdg/2004-May/002333.html">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</a><br> <br> --<br> Pat<br> </div> </span></font></div> <br> <hr> <font face="Arial" color="Gray" size="2"><br> Email Disclaimer: www.stjude.org/emaildisclaimer<br> Consultation Disclaimer: www.stjude.org/consultationdisclaimer<br> </font> </body> </html>