Re: inconsistency in basedir spec install in $datadir, search elsewhere

--_000_CH2PR04MB695078D43A0EF60E4FE13F1EE0952CH2PR04MB6950namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello Patrice,

Then I don't understand your concern.  Again, yes, it is possible for softw=
are 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 poi=
nts to any kind of flaw or inconsistency in the specifications.  I would ac=
count such an issue as arising from failure to comply with Basedir.

With respect specifically to $datadir, I urge you to consider how to interp=
ret 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 wer=
e more explicit about its meaning, but I see no good justification for choo=
sing an interpretation that makes the spec's provisions problematic.


Best regards,

John Bollinger
________________________________
From: Patrice Dumas <[email protected]>
Sent: Tuesday, August 27, 2024 6:03 PM
To: Bollinger, John <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: inconsistency in basedir spec install in $datadir, search else=
where

[You don't often get email from [email protected]. Learn why this is importa=
nt at https://aka.ms/LearnAboutSenderIdentification ]

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


On Tue, Aug 27, 2024 at 09:48:38PM +0000, Bollinger, John wrote:
> 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 envir=
onment of the installation program, but rather as a placeholder *in the spe=
c*, representing an arbitrary directory in the path specified by $XDG_DATA_=
DIRS, or representing the specified default value in the event that $XDG_DA=
TA_DIRS is unset or empty.

I do not not take "$datadir" to be an actual environment variable in the
spec, but definitively a variable, as a shell-like syntax is used.
Now, I can't see why you assume that it represents a directory in
$XDG_DATA_DIRS, nothing says it anywhere.  The only thing we know is
that it should default to /usr/share, which is one of the possibility
for the $XDG_DATA_DIRS default values (though not the first one, but why
not), not much more.

> So yes, if the value of $XDG_DATA_DIRS observed by an installation progra=
m is used to choose installation directories, and that differs from the val=
ue 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.  Bu=
t that has nothing to do with an environment variable named $datadir.

I never said that $XDG_DATA_DIRS would be used by an installation
program to choose installation directories.  Also to me $datadir is not an
environment variable in the spec, but a way to denote where data files
are installed.

On $XDG_DATA_DIRS being used by an installation program to choose
installation directories, I actually think that it is probably unusual,
and is not what GNU/Linux distributions do in their building
infrastructure usually, they set compile time options, for example
./configure options corresponding to the location denoted as $datadir in
the specification to abide to the Filesystem Hierarchy standard.  Users
can also choose other installation directories, often /usr/local when
installing from source, but could also be /opt... and I guess that some
installers could use $XDG_DATA_DIRS, but it is is probably unusual.

> More importantly, however, that's not how XDG Basedir is typically used i=
n practice. It is more common that an environment chooses installation dire=
ctories for software, data files, etc in some characteristic, systematic ma=
nner, and sets $XDG_DATA_DIRS such that programs will find their files in t=
he chosen locations.  That is, the choice of $XDG_DATA_DIRS is normally a f=
unction of the environment's installation practices, not the other way arou=
nd.

I agree here that what you describe is the usual use case.  We could,
however, imagine many other possibilities (systematic installation in
/usr/share, no $XDG_DATA_DIRS set, installation in /opt, $XDG_DATA_DIRS
manually set after installation by a computer administrator in a place
where all the users find the variable for instance using the
environment.d service...). Fortunately, $XDG_DATA_DIRS and installation
directories are set consistently in practice.  My point is not that
people are dumb, but that the specification is not avoiding
inconsistentcies, and, rather, that lots of situations that are allowed
by the specification lead to inconsistent installation and search.  Not
necessarily an issue, but would deserve an explanation.

--
Pat

________________________________

Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer

--_000_CH2PR04MB695078D43A0EF60E4FE13F1EE0952CH2PR04MB6950namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
Hello Patrice,</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
Then I don't understand your concern.&nbsp; Again, yes, it is possible for =
software to be installed, and the Basedir variables set, such that the inst=
alled software does not find its files at runtime.&nbsp; But I don't see ho=
w this points to any kind of flaw or inconsistency
 in the specifications.&nbsp; I would account such an issue as arising from=
 failure to comply with Basedir.</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
With respect specifically to $datadir, I urge you to consider how to interp=
ret the spec's use of that symbol in context, in a way that makes the spec =
sensible and consistent.&nbsp; I think that will bring you to an interpreta=
tion similar to the one I presented earlier.&nbsp;
 It would be better if the spec were more explicit about its meaning, but I=
 see no good justification for choosing an interpretation&nbsp;that makes t=
he spec's provisions problematic.</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
Best regards,</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
John Bollinger</div>
<div id=3D"appendonsend"></div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> Patrice Dumas &lt;per=
[email protected]&gt;<br>
<b>Sent:</b> Tuesday, August 27, 2024 6:03 PM<br>
<b>To:</b> Bollinger, John &lt;[email protected]&gt;<br>
<b>Cc:</b> [email protected] &lt;[email protected]&gt;<br>
<b>Subject:</b> Re: inconsistency in basedir spec install in $datadir, sear=
ch elsewhere</font>
<div>&nbsp;</div>
</div>
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;=
">
<div class=3D"PlainText">[You don't often get email from [email protected]. =
Learn why this is important at
<a href=3D"https://aka.ms/LearnAboutSenderIdentification">https://aka.ms/Le=
arnAboutSenderIdentification</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>
&gt; Hello Patrice,<br>
&gt;<br>
&gt; I think you're misunderstanding the use of &quot;$datadir&quot; in tha=
t 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 placeholde=
r *in the spec*, representing an arbitrary directory
 in the path specified by $XDG_DATA_DIRS, or representing the specified def=
ault value in the event that $XDG_DATA_DIRS is unset or empty.<br>
<br>
I do not not take &quot;$datadir&quot; 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.&nbsp; The only thing we know is<b=
r>
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>
&gt; So yes, if the value of $XDG_DATA_DIRS observed by an installation pro=
gram is used to choose installation directories, and that differs from the =
value of the same variable observed by the installed program at runtime, th=
en it is possible that the program
 will not find its installed data files.&nbsp; But that has nothing to do w=
ith 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.&nbsp; Also to me $datadir is no=
t 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.&nbsp; User=
s<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>
&gt; More importantly, however, that's not how XDG Basedir is typically use=
d in practice. It is more common that an environment chooses installation d=
irectories 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.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; No=
t<br>
necessarily an issue, but would deserve an explanation.<br>
<br>
--<br>
Pat<br>
</div>
</span></font></div>
<br>
<hr>
<font face=3D"Arial" color=3D"Gray" size=3D"2"><br>
Email Disclaimer: www.stjude.org/emaildisclaimer<br>
Consultation Disclaimer: www.stjude.org/consultationdisclaimer<br>
</font>
</body>
</html>

--_000_CH2PR04MB695078D43A0EF60E4FE13F1EE0952CH2PR04MB6950namp_--