| 1 |
On Thu, 23 Mar 2017 20:30:40 +0000 |
| 2 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
| 3 |
|
| 4 |
> On Thu, 23 Mar 2017 21:22:54 +0100 |
| 5 |
> Alexis Ballier <aballier@g.o> wrote: |
| 6 |
> > Indeed, according to pms.git commit log, the rule was laxed because |
| 7 |
> > it was clearly an oversight in EAPI6 [1] and was the standard |
| 8 |
> > behavior in previous EAPIs. But in the same commit, an "harmless |
| 9 |
> > note" was added that "Ebuilds must not access the directory in |
| 10 |
> > global scope." in addition to the "May or may not exist" statement |
| 11 |
> > and "Not necessarily present when installing from a binary package" |
| 12 |
> > footnote. Please explain how this last addition is not a |
| 13 |
> > backwards-breaking change. PMS is not a tool to push your personal |
| 14 |
> > agenda of cleaning up the deve^^err tree. |
| 15 |
> |
| 16 |
> The original wording should probably have been something like "may or |
| 17 |
> may not exist, so ebuilds MUST NOT go poking around for it", but the |
| 18 |
> original wording was written assuming reasonable behaviour from |
| 19 |
> developers, and we deliberately chose not to go the SHALL, MUST NOT |
| 20 |
> route because of the added cost of developing a specification that's |
| 21 |
> safe from hostile implementers. |
| 22 |
> |
| 23 |
|
| 24 |
"reasonable" is not something that can be reasonably defined :) |
| 25 |
|
| 26 |
after a few dozens of emails, what i understand of the issue is: |
| 27 |
autoconf assumes either the eblit stuff is in the environment, or |
| 28 |
FILESDIR variable is empty or points to its files dir; this might be |
| 29 |
borderline but definitely not hostile. |
| 30 |
|
| 31 |
this breaks in the (hypothetical?) case where the package is installed |
| 32 |
from a binpkg *and* the binpkg format does not include the whole |
| 33 |
environment but rather a verbatim copy of the ebuild and its eclasses(*). |
| 34 |
|
| 35 |
if that's the buggy case, then it should definitely have been stated |
| 36 |
upfront on the bug and it would likely have been fixed long ago; |
| 37 |
failing that it just seems to be un-necessary nitpicking over a |
| 38 |
different interpretation of some wording |
| 39 |
|
| 40 |
|
| 41 |
(*) not sure how that can even work with env saving between phases but |
| 42 |
that's not the point |
Archives