So what are you looking for at this point, Peter?  I think we're well past any 
question of interpreting the details of the spec, and we've even delved a bit 
into its history and design goals and its intended usage model.  We get that 
you are unhappy about how its use interacts with certain software installation 
scenarios that you care about, but the Base Directory spec is not going to be 
changed in a way that would satisfy you because the result would no longer be 
recognizable as Base Directory.  And clearly, although I'm sure we will all 
acknowledge that BD does not serve every conceivable scenario satisfactorily, 
there is no general sentiment that that constitutes a major flaw in the spec.


Regards,

John


-----Original Message-----
From: xdg <xdg-boun...@lists.freedesktop.org> On Behalf Of Peter White
Sent: Monday, September 20, 2021 8:27 AM
To: xdg@lists.freedesktop.org
Subject: Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg

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


On Mon, Sep 20, 2021 at 08:50:45AM -0400, Elsie Hupp wrote:
> > The way you describe it, it would be OK for any app to just parse the 
> > config of any other. That just feels wrong, because app A should have no 
> > business snooping in /etc/xdg/B/Brc. If app B wants to make such 
> > information available to others it should export it instead of requiring 
> > those to parse the file.
>
> To be fair, this is one of the motivations behind Flatpak and Snap. If you 
> don’t want one app snooping where it shouldn’t, then you make it technically 
> unable to do so.

Yes, and then there is XDG which expects exactly that, which then leads to 
other hacks to soften the isolation of said containers, or the inclusion of 
files which the go out of sync and out of date compared to what is in the real 
/etc. If I need hard sandboxing to stop such behaviour, then there is a serious 
bug in the spec. ;)


Best,
PW

P.S.: Please do not attach the whole history.

________________________________

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

Reply via email to