| 1 |
On 05/10/2016 02:28 PM, Mike Gilbert wrote: |
| 2 |
> On Tue, May 10, 2016 at 11:08 AM, Michael Orlitzky <mjo@g.o> wrote: |
| 3 |
>> We have maybe 150 ebuilds in the tree using $ROOT in src_* functions. |
| 4 |
>> Some are bugs, but many look OK to me. Do we really want to say "never" |
| 5 |
>> do that? |
| 6 |
> |
| 7 |
> According to PMS, it is only legal in pkg functions. |
| 8 |
> |
| 9 |
> Can you point to an example where using ROOT in a src function is appropriate? |
| 10 |
> |
| 11 |
|
| 12 |
Modulo the question "when should you use $ROOT over $EPREFIX"... |
| 13 |
|
| 14 |
* the chrome-binary-plugins ebuilds use it in src_install. |
| 15 |
|
| 16 |
* dmraid does |
| 17 |
|
| 18 |
einfo "Appending pkg.m4 from system to aclocal.m4" |
| 19 |
cat "${ROOT}"/usr/share/aclocal/pkg.m4 >>"${S}"/aclocal.m4 || \ |
| 20 |
die "Could not append pkg.m4 |
| 21 |
|
| 22 |
Both of those look like EPREFIX candidates to me, but they're not |
| 23 |
obviously wrong, either. Maybe it made sense in EAPI <= 3. |
| 24 |
|
| 25 |
Anywhere that you need addpredict() it also seems reasonable. The |
| 26 |
v4l-dvb-saa716x ebuilds use "${ROOT}/usr/src/linux/" where EPREFIX would |
| 27 |
not be a good replacement. |
| 28 |
|
| 29 |
Something needs to be fixed, though: you're right that the PMS limits |
| 30 |
ROOT to pkg_*. Who knew? If we want to be serious about banning ROOT in |
| 31 |
src_*, we should add a repoman error. |
| 32 |
|
| 33 |
NB: the patch uses the HTTP spelling of "refering". |
Archives