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 ADE5B138A1F for ; Sun, 26 Jan 2014 23:05:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0C86AE0D81; Sun, 26 Jan 2014 23:05:21 +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 0B97AE0D7A for ; Sun, 26 Jan 2014 23:05:19 +0000 (UTC) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (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 3CBD733F4CD for ; Sun, 26 Jan 2014 23:05:19 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id e14so5100063iej.17 for ; Sun, 26 Jan 2014 15:05: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=w1xoq4f8jB4k/2CXvPgjF8UXZv0xTCgneKJcJKHlD+4=; b=FdpPvvMmgYQ4O+ewPd2fL0azKpxADpkBlJifQMkUaWr9z9uUJfKvVt9GjkuFuG8XWh re8+e7lv0FNQDAy1hTuVSFFsDCdkjR3E1QMNxF2FYuxb374Y+6jQ6LvQeEllaUJB53rk 5OZrq6XpCUB35iRO7fc7tNqKbRjCE7Xe/o3VNAKOAxi2HddgcTXEhnP3SyJAu4/HrGug Ugfv7qV/p/8b97R1EUwrdv8Dznafjr7paaGWPj46rJFDvOABp6RmgXQQOBkfW9fXXmJd mwzo7Fou5Z2wuNme/6DeW/gIVDvAODRARRjc6nbLm60QjKtFyiUWwwwgHGJ14YSGS0zL 6TOQ== 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.28.72 with SMTP id z8mr14594949igg.44.1390777517922; Sun, 26 Jan 2014 15:05:17 -0800 (PST) Received: by 10.64.78.226 with HTTP; Sun, 26 Jan 2014 15:05:17 -0800 (PST) In-Reply-To: <20140126220347.720b12ed@googlemail.com> References: <20140125221628.26f3aa96@pomiot.lan> <20140126204926.33f2baef@googlemail.com> <20140126213527.1f5f6192@googlemail.com> <20140126225959.6f17bf8a@pomiot.lan> <20140126220347.720b12ed@googlemail.com> Date: Sun, 26 Jan 2014 18:05:17 -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: 6c52c8e2-dcbd-4400-9396-7bdceac3786d X-Archives-Hash: 6b93cf348e1cc417c873d8abd6e0a07f On Sun, Jan 26, 2014 at 5:03 PM, Ciaran McCreesh wrote: > On Sun, 26 Jan 2014 22:59:59 +0100 > Micha=C5=82 G=C3=B3rny wrote: >> Dnia 2014-01-26, o godz. 21:35:27 >> Ciaran McCreesh napisa=C5=82(a): >> > On Sun, 26 Jan 2014 13:21:44 -0800 >> > Alec Warner wrote: >> > > Sorry, I work on Portage. What I'm saying is that We are free to >> > > change the behavior of *portage* now; rather than waiting for a >> > > new EAPI. If an ebuild needs to define EAPI=3Deapi-next to >> > > 'correctly' use XDG_*, well that is someone else's can of worms. >> > >> > Changing Portage to hide the issue is a bad idea, since it makes it >> > harder for developers to notice that that's a problem they need to >> > fix. Although maybe you could set XDG_* to something that will give >> > a big noisy sandbox violation for current EAPIs? >> >> Yes, because instantly breaking a few dozen ebuilds in stable tree for >> the sake of proving a point is always a good idea. > > It's not about proving a point, it's about fixing existing bugs. It's > changing a hard-to-see error into an easy-to-see error, so that it can > be fixed more quickly. This change would introduce no new breakage, > since anything affected by it is already broken. > Most people do not have XDG_CONFIG_HOME, etc. set in their environment, so having the package manager set it to something that intentionally breaks ebuilds is a step backward for most end users. It would really nice to have a solution for the few users who do have this set that does not involve adding code to random eclasses, or leaving things broken for X months/years until all ebuilds can be bumped to EAPI 6.