<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);">
Then I don't understand your concern. Again, yes, it is possible for software to be installed, and the Basedir variables set, such that the installed software does not find its files at runtime. But I don't see how this points to any kind of flaw or inconsistency
in the specifications. I would account such an issue as arising from failure to comply with Basedir.</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);">
With respect specifically to $datadir, I urge you to consider how to interpret the spec's use of that symbol in context, in a way that makes the spec sensible and consistent. I think that will bring you to an interpretation similar to the one I presented earlier.
It would be better if the spec were more explicit about its meaning, but I see no good justification for choosing an interpretation that makes the spec's provisions problematic.</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 regards,</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> Patrice Dumas <pertusus@free.fr><br>
<b>Sent:</b> Tuesday, August 27, 2024 6:03 PM<br>
<b>To:</b> Bollinger, John <John.Bollinger@STJUDE.ORG><br>
<b>Cc:</b> xdg@lists.freedesktop.org <xdg@lists.freedesktop.org><br>
<b>Subject:</b> Re: 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>
On Tue, Aug 27, 2024 at 09:48:38PM +0000, Bollinger, John wrote:<br>
> Hello Patrice,<br>
><br>
> 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.<br>
<br>
I do not not take "$datadir" to be an actual environment variable in the<br>
spec, but definitively a variable, as a shell-like syntax is used.<br>
Now, I can't see why you assume that it represents a directory in<br>
$XDG_DATA_DIRS, nothing says it anywhere. The only thing we know is<br>
that it should default to /usr/share, which is one of the possibility<br>
for the $XDG_DATA_DIRS default values (though not the first one, but why<br>
not), not much more.<br>
<br>
> 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.<br>
<br>
I never said that $XDG_DATA_DIRS would be used by an installation<br>
program to choose installation directories. Also to me $datadir is not an<br>
environment variable in the spec, but a way to denote where data files<br>
are installed.<br>
<br>
On $XDG_DATA_DIRS being used by an installation program to choose<br>
installation directories, I actually think that it is probably unusual,<br>
and is not what GNU/Linux distributions do in their building<br>
infrastructure usually, they set compile time options, for example<br>
./configure options corresponding to the location denoted as $datadir in<br>
the specification to abide to the Filesystem Hierarchy standard. Users<br>
can also choose other installation directories, often /usr/local when<br>
installing from source, but could also be /opt... and I guess that some<br>
installers could use $XDG_DATA_DIRS, but it is is probably unusual.<br>
<br>
> 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.<br>
<br>
I agree here that what you describe is the usual use case. We could,<br>
however, imagine many other possibilities (systematic installation in<br>
/usr/share, no $XDG_DATA_DIRS set, installation in /opt, $XDG_DATA_DIRS<br>
manually set after installation by a computer administrator in a place<br>
where all the users find the variable for instance using the<br>
environment.d service...). Fortunately, $XDG_DATA_DIRS and installation<br>
directories are set consistently in practice. My point is not that<br>
people are dumb, but that the specification is not avoiding<br>
inconsistentcies, and, rather, that lots of situations that are allowed<br>
by the specification lead to inconsistent installation and search. Not<br>
necessarily an issue, but would deserve an explanation.<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>