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 ACC58138A1F for ; Sun, 26 Jan 2014 21:21:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6B2A1E0DEE; Sun, 26 Jan 2014 21:21:46 +0000 (UTC) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 80200E0DE8 for ; Sun, 26 Jan 2014 21:21:45 +0000 (UTC) Received: by mail-ve0-f170.google.com with SMTP id cz12so3084714veb.15 for ; Sun, 26 Jan 2014 13:21:44 -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=9Pa4u1iA/De5DNa8FzjDWjxqfjftTX/i59SRwb5R/sU=; b=ZS3Jc6WhlgyzzL/m7VD/ylW+toKU0nK2gAQe71JjjuXVyrH1kdXgyi/0bkOgDu0QVt vseWgdh1zIC/JaxDwL8NMgZsISz6SjgELBtAjMhIT7ZFc1w0Xt/pgOS/+zgPWnEPbAu/ 9j4aNracUn+Z72xLdxyyFJ1ByysMYc/QUwQQ6GCo3ClPWKEWWzFRwZoxNepPy5IE3uuR fqnonJMibQ5dLsTdrZWlJwBNvQ/bsbss7WgkGewbUT/EZC9R0KzdmqgtRMsRZwNrBz/q w099bAXlcr0zAHHLjzGYcSJ5NQs39mcZBTBYj5LNlgL7sXLYKP7lhRat4esUwsKCGC0f KmdA== X-Gm-Message-State: ALoCoQmw2cIar4TsiX1F8+zPkjl2Dvo9+3/Jg/H8UkJ0UPehV90AdrIFYgO4UG2BUZenKje2Gs4M 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.52.30.77 with SMTP id q13mr1607378vdh.18.1390771304705; Sun, 26 Jan 2014 13:21:44 -0800 (PST) Sender: antarus@scriptkitty.com Received: by 10.220.59.71 with HTTP; Sun, 26 Jan 2014 13:21:44 -0800 (PST) X-Originating-IP: [173.8.165.226] In-Reply-To: <20140126204926.33f2baef@googlemail.com> References: <20140125221628.26f3aa96@pomiot.lan> <20140126204926.33f2baef@googlemail.com> Date: Sun, 26 Jan 2014 13:21:44 -0800 X-Google-Sender-Auth: ffTtt85-LT-5Xg5V1fkskQq_b6c Message-ID: Subject: Re: [gentoo-dev] Dealing with XDG directories in ebuild environment From: Alec Warner To: Gentoo Dev Content-Type: multipart/alternative; boundary=20cf3077614b94c5b704f0e62dde X-Archives-Salt: 9adb9767-0b8c-4ce6-abda-bdc5b2c056b9 X-Archives-Hash: d343cf3cbbbb398f6e8f7f1105b10b3c --20cf3077614b94c5b704f0e62dde Content-Type: text/plain; charset=UTF-8 On Sun, Jan 26, 2014 at 12:49 PM, Ciaran McCreesh < ciaran.mccreesh@googlemail.com> wrote: > On Sun, 26 Jan 2014 12:43:37 -0800 > Alec Warner wrote: > > I don't buy that. The behavior appears to be currently undefined. > > Changing it to different undefined behavior is allowed. > > The point of undefined behaviour is that anything that is relying upon > undefined behaviour doing a particular thing is broken. PMS doesn't > define what happens to XDG_*, so if your ebuilds need a particular > thing done for it then they must be fixed. > > Perhaps PMS should be more explicit in stating this -- we lifted the > concept of undefined behaviour from the C and C++ standards, and just > assumed that people would know what it meant. Maybe we need a bit more > text to clear up the misconception we see every now and again that > "undefined" somehow means "it's ok to assume what some version of > Portage happens to do, since the specification doesn't say you can't > do that"... > 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=eapi-next to 'correctly' use XDG_*, well that is someone else's can of worms. -A > > -- > Ciaran McCreesh > --20cf3077614b94c5b704f0e62dde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Jan 26, 2014 at 12:49 PM, Ciaran McCreesh <ciaran.mccrees= h@googlemail.com> wrote:
On Sun, 26 Jan 2014 12:43:= 37 -0800
Alec Warner <antarus@gentoo.org> wrote:
> I don't buy that. The behavior appears to be currently undefined.<= br> > Changing it to different undefined behavior is allowed.

The point of undefined behaviour is that anything that is relying upo= n
undefined behaviour doing a particular thing is broken. PMS doesn't
define what happens to XDG_*, so if your ebuilds need a particular
thing done for it then they must be fixed.

Perhaps PMS should be more = explicit in stating this -- we lifted the
concept of undefined behaviour from the C and C++ standards, and just
assumed that people would know what it meant. Maybe we need a bit more
text to clear up the misconception we see every now and again that
"undefined" somehow means "it's ok to assume what some v= ersion of
Portage happens to do, since the specification doesn't say you can'= t
do that"...


-A
=C2=A0

--
Ciaran McCreesh

--20cf3077614b94c5b704f0e62dde--