From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id EE2B7138A1F for ; 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 ; Sun, 26 Jan 2014 20:43:37 +0000 (UTC) Received: by mail-vb0-f51.google.com with SMTP id 11so2929780vbe.38 for ; 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: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail 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: References: <20140125221628.26f3aa96@pomiot.lan> Date: Sun, 26 Jan 2014 12:43:37 -0800 X-Google-Sender-Auth: 8Pgt6kJGmX_8Wxq2BBURe7_D66U Message-ID: Subject: Re: [gentoo-dev] Dealing with XDG directories in ebuild environment From: Alec Warner To: Gentoo Dev 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 wrote: > On Sat, Jan 25, 2014 at 7:10 PM, Mike Gilbert wrote: > > On Sat, Jan 25, 2014 at 4:16 PM, Micha=C5=82 G=C3=B3rny wrote: > >> Dnia 2014-01-25, o godz. 11:13:38 > >> Mike Gilbert 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
On S= at, Jan 25, 2014 at 4:19 PM, Mike Gilbert <floppym@gentoo.org> wrote:
On Sat, Jan 25, 2014 at 7:10 PM, M= ike Gilbert <flo= ppym@gentoo.org> wrote:
> On Sat, Jan 25, 2014 at 4:16 PM, Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org> wrot= e:
>> 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<= br> >>> environment when calling emerge has a tendency to cause sandbo= x
>>> 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 c= an 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<= br> >>> 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 env= ironment.
>> 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 woul= d need
to be an EAPI change, which means quite a long wait.
<= br>
I don't buy that. The behavior appears to be currently un= defined. 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.<= /div>

-A
=C2=A0

https://bugs.gentoo.org/show_bug.cgi?id=3D444568


--001a11c322743da3e804f0e5a596--