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 8F7F4138A1F for ; Sun, 26 Jan 2014 20:49:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A9B6CE0DDB; Sun, 26 Jan 2014 20:49:41 +0000 (UTC) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A7FF9E0D86 for ; Sun, 26 Jan 2014 20:49:40 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id n12so3544798wgh.0 for ; Sun, 26 Jan 2014 12:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type; bh=KjDZr2PYzIsjF9GUPlpP8DZ4MWnqCbgtCQiF59MasCk=; b=APM2CJGZ6LxPrpjJZK3CsDnvWlUkDfFM6xUAAj2xYWO6LDWupCqoVtuQNyES1g0Xf0 iMUp7C6Tfv9EV8/rcd7eCAguVLjeOmMUEd9YQYGeVFvuIY1CL/R+ssumFz2DJO+AzqN8 l4pTQFoVfl2O2jmlk/Ut7rT5R0utu7Ynb+7FDE67Oy51i2pKzfw6KZosbiXWKGC3lA8L tYPyU2JvKwPN+zhQquOuf2gPA4TCFbMKvWAw5FPfFGdquXVSf06LhPmCxt4CmFTKdQ4n MUUn5tSfkO79HbWLqCwHspSkUQtGqHCNFAcH+L9uUXxr6j7S2xCCCBWBckPFq681KbCB W0mw== X-Received: by 10.194.143.40 with SMTP id sb8mr17854180wjb.15.1390769379466; Sun, 26 Jan 2014 12:49:39 -0800 (PST) Received: from localhost (cpc3-broo7-2-0-cust157.14-2.cable.virginm.net. [86.30.224.158]) by mx.google.com with ESMTPSA id po3sm19935079wjc.3.2014.01.26.12.49.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jan 2014 12:49:38 -0800 (PST) Date: Sun, 26 Jan 2014 20:49:26 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Dealing with XDG directories in ebuild environment Message-ID: <20140126204926.33f2baef@googlemail.com> In-Reply-To: References: <20140125221628.26f3aa96@pomiot.lan> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-pc-linux-gnu) 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 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/xRSRLjfhXZOJF1TDTulQ.iH"; protocol="application/pgp-signature" X-Archives-Salt: dfad6676-d5e5-4d28-b8d3-591c9ea5315b X-Archives-Hash: 73381904ac619c926dd15521a82abbba --Sig_/xRSRLjfhXZOJF1TDTulQ.iH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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"... --=20 Ciaran McCreesh --Sig_/xRSRLjfhXZOJF1TDTulQ.iH Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlLldN8ACgkQ96zL6DUtXhEK2gCfTemjO3dVcktuSiquom2G5SGp 2NMAoKmv+5OPXUjkPP7FcoU4A9l709Zj =LbRe -----END PGP SIGNATURE----- --Sig_/xRSRLjfhXZOJF1TDTulQ.iH--