From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 264BE139694 for ; Thu, 23 Mar 2017 21:45:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DF18621C1BF; Thu, 23 Mar 2017 21:45:46 +0000 (UTC) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7719621C0E0 for ; Thu, 23 Mar 2017 21:45:46 +0000 (UTC) Received: by mail-wm0-x243.google.com with SMTP id z133so1894143wmb.2 for ; Thu, 23 Mar 2017 14:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=vz4Q0c7N0JSOF1a/yIwBLOu4syU/cke9MjGTNDGBAFw=; b=kcZJP1xw0Ja3a44BnhkmhnzgSM8/l6Pxhg7nF+6Afg/bA1qXjMDH/b1GSWkecMbpaI Q0aF5vAGYI0DKcT5svn1bZQXUkJPYsTxRQL2ad5stI9UznIwVLPERNnoubKhPtbXZ9yP lgBqQHv4uzIsmI/PGwX+BEFqVG90HzeT6JgwT0Sfm7Ln1xm89fawVFU3TJei4KRN+6qE aGmLccF3nNgy30abCjFcgslF6T10rDCJHQuXkrYP0GmpiuNkigFFMKMQaTA8tN731a2R /Et9dNl2ef8ZxilObj28xlKAxvmJP1x6VIgkfT2/ycBMh7Z3rOpngR2tFB00DxM2lDl0 02IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=vz4Q0c7N0JSOF1a/yIwBLOu4syU/cke9MjGTNDGBAFw=; b=NLq2hdrFyUC2ZBUlf0coUwqfjeQLxftz3L1mMzHHoltoQghJ9UWvO5VjNU3X+/nw9b TswwG/YBvQXTyNb3e3zKgYu7CFdKjHyZ84XqtpZuV+jcw+0Q2vxliHvidx9pa0NRuR07 A5SZ+kifeR92KitWEGEHmAMbEB/sHMO1ha//Ag+oyTektID9ScbDDpqlpcqHQJwAgTfb xCBRavziXNqkYZLvlT69iWkVr0Fnxs/Nv64unN4WRmD94Wu9frsbq5dWIgIbD0djCYIb Z/AGyNJeaYoaCDV1xnuGezDEAlnX+dBvli1v3xIDVfUMdQrPNCahcDNJ1R/Jcm4X2GR9 Cx9w== X-Gm-Message-State: AFeK/H2dwP1dv5spDo5r6ZehAkBvOnf8d9/0G2Jv9X4HpyvovIBAt7d2bqzSaGdeTxdLvA== X-Received: by 10.28.88.129 with SMTP id m123mr5170195wmb.28.1490305544927; Thu, 23 Mar 2017 14:45:44 -0700 (PDT) Received: from snowblower (cpc14-broo7-2-0-cust7.14-2.cable.virginm.net. [82.0.20.8]) by smtp.gmail.com with ESMTPSA id k139sm5998982wmg.11.2017.03.23.14.45.44 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 23 Mar 2017 14:45:44 -0700 (PDT) Date: Thu, 23 Mar 2017 21:45:41 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424 Message-ID: <20170323214541.78eff3c1@snowblower> In-Reply-To: <20170323223749.71de6c09@gentoo.org> References: <20170316093806.31977-1-mgorny@gentoo.org> <20170320083544.GZ24205@vapier> <2240597.YoP4Ev77Vx@porto> <1652433.oqbzW57v8l@porto> <20170323105101.0f622f66@gentoo.org> <1490288005.1534.1.camel@gentoo.org> <20170323195213.406ba9f8@gentoo.org> <1490295612.1534.3.camel@gentoo.org> <20170323212254.1bb17f3d@gentoo.org> <20170323203040.598f6278@snowblower> <20170323223749.71de6c09@gentoo.org> X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.31; 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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: eb62239b-8ba0-4eab-8927-62e1aa087e56 X-Archives-Hash: 446366b36556ae69b79e7ed019af36f9 On Thu, 23 Mar 2017 22:37:49 +0100 Alexis Ballier wrote: > On Thu, 23 Mar 2017 20:30:40 +0000 > Ciaran McCreesh wrote: > > On Thu, 23 Mar 2017 21:22:54 +0100 > > Alexis Ballier wrote: > > > Indeed, according to pms.git commit log, the rule was laxed > > > because it was clearly an oversight in EAPI6 [1] and was the > > > standard behavior in previous EAPIs. But in the same commit, an > > > "harmless note" was added that "Ebuilds must not access the > > > directory in global scope." in addition to the "May or may not > > > exist" statement and "Not necessarily present when installing > > > from a binary package" footnote. Please explain how this last > > > addition is not a backwards-breaking change. PMS is not a tool to > > > push your personal agenda of cleaning up the deve^^err tree. > > > > The original wording should probably have been something like "may > > or may not exist, so ebuilds MUST NOT go poking around for it", but > > the original wording was written assuming reasonable behaviour from > > developers, and we deliberately chose not to go the SHALL, MUST NOT > > route because of the added cost of developing a specification that's > > safe from hostile implementers. > > "reasonable" is not something that can be reasonably defined :) There's a fairly good rule of thumb: is anyone else already doing this horrible new thing you're about to add to the tree? If not, it's probably not reasonable. > after a few dozens of emails, what i understand of the issue is: > autoconf assumes either the eblit stuff is in the environment, or > FILESDIR variable is empty or points to its files dir; this might be > borderline but definitely not hostile. No, the issue is that eblits are a dodgy mechanism that go beyond what ebuilds are supposed to do and that cause problems for package manglers. When we're working with a general purpose shell underneath, it's very hard to write a specification that can preemptively forbid every kind of perverse mess any developer can come up with, particularly when the developer starts looking for loopholes like claiming it's OK to try to access a directory which is defined as potentially not existing when the clear intent of the specification is that "the directory isn't guaranteed to be there so don't try to use it for anything". > this breaks in the (hypothetical?) case where the package is installed > from a binpkg *and* the binpkg format does not include the whole > environment but rather a verbatim copy of the ebuild and its > eclasses(*). > > (*) not sure how that can even work with env saving between phases but > that's not the point It can't, so that weird hypothetical is irrelevant. But more to the point, we're only wondering about these weird hypothetical situations because someone felt the need to make everyone's life a misery by putting some special snowflake code in the tree. -- Ciaran McCreesh