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 218E7138B32 for ; Sun, 26 Jan 2014 00:19:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 40393E0ADC; Sun, 26 Jan 2014 00:19:39 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 59BA3E0A8E for ; Sun, 26 Jan 2014 00:19:38 +0000 (UTC) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: floppym) by smtp.gentoo.org (Postfix) with ESMTPSA id 9442E33F65A for ; Sun, 26 Jan 2014 00:19:37 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id ar20so4443374iec.10 for ; Sat, 25 Jan 2014 16:19:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=G1uf/2uL47MHq/QZrLd25UdoVsPtkj+5PqMLeLr1ao4=; b=d+PMwidJg4f24nTbMIKJsPhabIzAuaZNYHkqAlnwY/tQC0/YQFpEugCCgFJUMWNNeF Wv/1strEf3IJmIUfYAS4854CU873G4JFS9rITMDt/bBjPwqslHtxRaud20UX+wVJZ0oz zjDoP8ifRMiYr26O5ULlZxNio7jgkc+5f1eKYkQifPbETJxvVlgXRf8sMYphkXXXnHHU 8UeCLCSoJHhqsU7Uh0tSipaCJ1ybyoF/I4FqE5IgLfRVHSbyI5osIzCr68kFhfFWS+7t AaFq3bPapKb66Ba3SkDll7qvxxHtrsn0WbANPLaXYVpWZ+iVxtOzWUJEIEiY+zMOJ2re xb1g== 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.50.138.72 with SMTP id qo8mr11220215igb.8.1390695576252; Sat, 25 Jan 2014 16:19:36 -0800 (PST) Received: by 10.64.86.234 with HTTP; Sat, 25 Jan 2014 16:19:36 -0800 (PST) In-Reply-To: References: <20140125221628.26f3aa96@pomiot.lan> Date: Sat, 25 Jan 2014 19:19:36 -0500 Message-ID: Subject: Re: [gentoo-dev] Dealing with XDG directories in ebuild environment From: Mike Gilbert To: Gentoo Dev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 8d92d0a9-26b1-4d4e-b725-06aa0a345f21 X-Archives-Hash: 2e1871fd73897222360c5897fdddb285 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. https://bugs.gentoo.org/show_bug.cgi?id=3D444568