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 C6084138B32 for ; Sun, 26 Jan 2014 00:10:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 99E9EE0AD4; Sun, 26 Jan 2014 00:10:20 +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 B245BE0A70 for ; Sun, 26 Jan 2014 00:10:19 +0000 (UTC) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (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 94B7A33F6D6 for ; Sun, 26 Jan 2014 00:10:18 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id x13so4480202ief.9 for ; Sat, 25 Jan 2014 16:10:17 -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=5hsNMnHHR7MhQkmCaCuCYFqv1EpNgfEhJZUZ8zd6DzI=; b=ZM+RYIGg0r/53z/bjFy+DwH4c6LrIwtqnRU0/3gUKpzu6IN8vJvz3FkY2WzukrGb/p DbnTy3K7r9T9+rX4rTCV68h8LJUUJsCjGOtQfblZkPD9OhHknu9jZt2+k79Xv1WtEjuM vGvtdNC84OnVBsnfvwIvWs32obPcSRNMRirOjf4qRmzjpviNNyHzn+RLE1NhSLiqhpLr 5ZyOwokMu0zc7ctGJHVWQNiP/VucBwjNpnsOJeAlrcRMKKAqlv0zG66EHm0Istt+Y5o0 LVeedzI1rkkur/mHE8JnPtMOvd8ysXCUcE8j8rcjTyJp7QyaZ/ULMetRinHdztHp90q+ HvTA== 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.78.200 with SMTP id d8mr11160461igx.38.1390695016987; Sat, 25 Jan 2014 16:10:16 -0800 (PST) Received: by 10.64.86.234 with HTTP; Sat, 25 Jan 2014 16:10:16 -0800 (PST) In-Reply-To: <20140125221628.26f3aa96@pomiot.lan> References: <20140125221628.26f3aa96@pomiot.lan> Date: Sat, 25 Jan 2014 19:10:16 -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: 8e9ca08b-5d6f-4d66-b408-a5a6752eafbe X-Archives-Hash: dbfc4cb5e655453c8d9b4e6ce54b8bb6 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