On Thu, 23 Mar 2017 20:30:40 +0000 Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> On Thu, 23 Mar 2017 21:22:54 +0100 > Alexis Ballier <aball...@gentoo.org> 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 :) 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. 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(*). if that's the buggy case, then it should definitely have been stated upfront on the bug and it would likely have been fixed long ago; failing that it just seems to be un-necessary nitpicking over a different interpretation of some wording (*) not sure how that can even work with env saving between phases but that's not the point
