| 1 |
>>>>> On Mon, 20 Mar 2017, Mike Frysinger wrote: |
| 2 |
|
| 3 |
> obvious NAK until you sort out the open questions already raised |
| 4 |
> about the backwards breaking change you're trying to land in PMS. |
| 5 |
|
| 6 |
There are indeed some PMS patches pending about DISTDIR, FILESDIR, |
| 7 |
WORKDIR, and S, but I fail to see where they would break backwards |
| 8 |
compatibility. |
| 9 |
|
| 10 |
If you look at the last council approved PMS version [1], you'll find |
| 11 |
that DISTDIR and FILESDIR are only valid in src_* phases and are not |
| 12 |
guaranteed to have a consistent value across phases. The problem with |
| 13 |
this is that it would not allow assignment of the PATCHES array in |
| 14 |
global scope, e.g.: |
| 15 |
|
| 16 |
PATCHES=( "${DISTDIR}"/foo.patch "${WORKDIR}"/bar.patch ) |
| 17 |
|
| 18 |
After the PMS change, we will have the same properties for DISTDIR, |
| 19 |
FILESDIR, WORKDIR, and S. Namely: |
| 20 |
|
| 21 |
- All four variables will be valid in src_* phases and in global scope |
| 22 |
- They will have a consistent value in the ebuild environment |
| 23 |
- The actual directories must not be accessed in global scope |
| 24 |
|
| 25 |
One could argue that this was overseen when EAPI 6 was approved. |
| 26 |
In any case, ebuilds will be able to rely on more things than before. |
| 27 |
|
| 28 |
Ulrich |
| 29 |
|
| 30 |
[1] https://projects.gentoo.org/pms/6/pms.html#x1-118002 |
Archives