From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-64589-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id EE2B7138A1F
for <garchives@archives.gentoo.org>; Sun, 26 Jan 2014 20:43:44 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 3EC3EE0DA4;
Sun, 26 Jan 2014 20:43:39 +0000 (UTC)
Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 39754E0D7B
for <gentoo-dev@lists.gentoo.org>; Sun, 26 Jan 2014 20:43:37 +0000 (UTC)
Received: by mail-vb0-f51.google.com with SMTP id 11so2929780vbe.38
for <gentoo-dev@lists.gentoo.org>; Sun, 26 Jan 2014 12:43:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:date
:message-id:subject:from:to:content-type;
bh=Xhb87vHsW1c0pZ/OHXylz+j9Sv7nWx5dKgJ+qJY+HTQ=;
b=Q2Tw7ygf/SGolGjoJ1LezdFB2B1OKwf04R8Pcvew0Em62dOO0gDNk9CYmQzljN5AYq
lGilgg/IXuSavyo3nXZP5/Rwp4PzOURcqahwfADdX7rFt8jLY8k6nLKzM4YiCzZQzJMf
1rJaqz3eDRaoqq3EEWRwHG6xNALfwlaqb7yaopr9OVXI3oZRue1N+rWwgHWsOU1npWF/
ZRyt34OMIjDm/if60Yfla9GaZxxCGFuMq1OP0DNuB8UiUf+okQVmLQ9LwmUe92lvp55r
V67ijd1BSkoMf3GllSfi3zIoPaD0DD2fxv5T7GCVEGPIYbhFifMlqCXSTpy9rap+vPXa
HVXQ==
X-Gm-Message-State: ALoCoQmI+SMUmOLS3SzGpv37TOxAJK6ujTOVnmmqdFT3bUHlJxz5KknTexVE3KDv/0z4DQisXWZL
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
X-Received: by 10.58.119.161 with SMTP id kv1mr13535916veb.21.1390769017293;
Sun, 26 Jan 2014 12:43:37 -0800 (PST)
Sender: antarus@scriptkitty.com
Received: by 10.220.59.71 with HTTP; Sun, 26 Jan 2014 12:43:37 -0800 (PST)
X-Originating-IP: [173.8.165.226]
In-Reply-To: <CAJ0EP413Gey7GiZ4WqvWA1wvPeeoGtRu0cgb0_OqnZB3E0EsAA@mail.gmail.com>
References: <CAJ0EP42143-BM5sQHbjP4ua-F-GMzQKk-23_BGMb=EjCDK59iw@mail.gmail.com>
<20140125221628.26f3aa96@pomiot.lan>
<CAJ0EP43YYh50tjuhmfm05mLAckoQLM-u+XqNkS1izuky6q09jg@mail.gmail.com>
<CAJ0EP413Gey7GiZ4WqvWA1wvPeeoGtRu0cgb0_OqnZB3E0EsAA@mail.gmail.com>
Date: Sun, 26 Jan 2014 12:43:37 -0800
X-Google-Sender-Auth: 8Pgt6kJGmX_8Wxq2BBURe7_D66U
Message-ID: <CAAr7Pr9y1ohMviTCCU4n6-6AvJkUCzfeQiMAgLOWEK--zH+QFg@mail.gmail.com>
Subject: Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
From: Alec Warner <antarus@gentoo.org>
To: Gentoo Dev <gentoo-dev@lists.gentoo.org>
Content-Type: multipart/alternative; boundary=001a11c322743da3e804f0e5a596
X-Archives-Salt: b41f27a4-519e-4f74-9fcb-e8e6942f0c4f
X-Archives-Hash: 2a281cde6316bfb10024474108974789
--001a11c322743da3e804f0e5a596
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sat, Jan 25, 2014 at 4:19 PM, Mike Gilbert <floppym@gentoo.org> wrote:
> On Sat, Jan 25, 2014 at 7:10 PM, Mike Gilbert <floppym@gentoo.org> wrote:
> > On Sat, Jan 25, 2014 at 4:16 PM, Micha=C5=82 G=C3=B3rny <mgorny@gentoo.=
org> wrote:
> >> Dnia 2014-01-25, o godz. 11:13:38
> >> Mike Gilbert <floppym@gentoo.org> napisa=C5=82(a):
> >>
> >>> It seems having XDG variables like XDG_CONFIG_HOME set in the
> >>> environment when calling emerge has a tendency to cause sandbox
> >>> violations. For example, see the bugs blocking bug 499202.
> >>>
> >>> https://bugs.gentoo.org/show_bug.cgi?id=3D499202
> >>>
> >>> If you grep for XDG_CONFIG_HOME in the eclass directory, you can see
> >>> that several eclasses work around this by setting
> >>> XDG_CONFIG_HOME=3D"${T}" or "${T}/.config".
> >>>
> >>> gnome2-utils.eclass takes it a step further and creates empty
> >>> directories for several other XDG variables.
> >>>
> >>> Is this something we can/should consolidate into some central place?
> >>> Or should I just copy/paste something into distutils-r1.eclass?
> >>
> >> I'd say portage should kill that as part of sanitizing the environment=
.
> >> There's no point in reproducing it in random eclasses.
> >>
> >
> > I have filed an enhancement request for Portage.
> >
> > https://bugs.gentoo.org/show_bug.cgi?id=3D499288
>
> It seems Arfrever beat me to it. However, it looks like it would need
> to be an EAPI change, which means quite a long wait.
>
I don't buy that. The behavior appears to be currently undefined. Changing
it to different undefined behavior is allowed.
If EAPI-NEXT wants to define the behavior of XDG_* then that is fine too,
we will just be ahead of the curve, rather than behind.
-A
>
> https://bugs.gentoo.org/show_bug.cgi?id=3D444568
>
>
--001a11c322743da3e804f0e5a596
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Jan 25, 2014 at 4:19 PM, Mike Gilbert <span dir=3D"ltr"><<a href=3D"=
mailto:floppym@gentoo.org" target=3D"_blank">floppym@gentoo.org</a>></sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><div>On Sat, Jan 25, 2014 at 7:10 PM, M=
ike Gilbert <<a href=3D"mailto:floppym@gentoo.org" target=3D"_blank">flo=
ppym@gentoo.org</a>> wrote:<br>
> On Sat, Jan 25, 2014 at 4:16 PM, Micha=C5=82 G=C3=B3rny <<a href=3D=
"mailto:mgorny@gentoo.org" target=3D"_blank">mgorny@gentoo.org</a>> wrot=
e:<br>
>> Dnia 2014-01-25, o godz. 11:13:38<br>
>> Mike Gilbert <<a href=3D"mailto:floppym@gentoo.org" target=3D"_=
blank">floppym@gentoo.org</a>> napisa=C5=82(a):<br>
>><br>
>>> It seems having XDG variables like XDG_CONFIG_HOME set in the<=
br>
>>> environment when calling emerge has a tendency to cause sandbo=
x<br>
>>> violations. For example, see the bugs blocking bug 499202.<br>
>>><br>
>>> <a href=3D"https://bugs.gentoo.org/show_bug.cgi?id=3D499202" t=
arget=3D"_blank">https://bugs.gentoo.org/show_bug.cgi?id=3D499202</a><br>
>>><br>
>>> If you grep for XDG_CONFIG_HOME in the eclass directory, you c=
an see<br>
>>> that several eclasses work around this by setting<br>
>>> XDG_CONFIG_HOME=3D"${T}" or "${T}/.config"=
.<br>
>>><br>
>>> gnome2-utils.eclass takes it a step further and creates empty<=
br>
>>> directories for several other XDG variables.<br>
>>><br>
>>> Is this something we can/should consolidate into some central =
place?<br>
>>> Or should I just copy/paste something into distutils-r1.eclass=
?<br>
>><br>
>> I'd say portage should kill that as part of sanitizing the env=
ironment.<br>
>> There's no point in reproducing it in random eclasses.<br>
>><br>
><br>
> I have filed an enhancement request for Portage.<br>
><br>
> <a href=3D"https://bugs.gentoo.org/show_bug.cgi?id=3D499288" target=3D=
"_blank">https://bugs.gentoo.org/show_bug.cgi?id=3D499288</a><br>
<br>
</div></div>It seems Arfrever beat me to it. However, it looks like it woul=
d need<br>
to be an EAPI change, which means quite a long wait.<br></blockquote><div><=
br></div><div>I don't buy that. The behavior appears to be currently un=
defined. Changing it to different undefined behavior is allowed.</div>
<div><br></div><div>If EAPI-NEXT wants to define the behavior of XDG_* then=
that is fine too, we will just be ahead of the curve, rather than behind.<=
/div><div><br></div><div>-A</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<a href=3D"https://bugs.gentoo.org/show_bug.cgi?id=3D444568" target=3D"_bla=
nk">https://bugs.gentoo.org/show_bug.cgi?id=3D444568</a><br>
<br>
</blockquote></div><br></div></div>
--001a11c322743da3e804f0e5a596--