1 |
On Tue, 10 May 2016 21:42:19 -0400 |
2 |
Mike Gilbert <floppym@g.o> wrote: |
3 |
|
4 |
> On Tue, May 10, 2016 at 5:25 PM, Michael Orlitzky <mjo@g.o> |
5 |
> wrote: |
6 |
> > On 05/10/2016 02:28 PM, Mike Gilbert wrote: |
7 |
> >> On Tue, May 10, 2016 at 11:08 AM, Michael Orlitzky |
8 |
> >> <mjo@g.o> wrote: |
9 |
> >>> We have maybe 150 ebuilds in the tree using $ROOT in src_* |
10 |
> >>> functions. Some are bugs, but many look OK to me. Do we really |
11 |
> >>> want to say "never" do that? |
12 |
> >> |
13 |
> >> According to PMS, it is only legal in pkg functions. |
14 |
> >> |
15 |
> >> Can you point to an example where using ROOT in a src function is |
16 |
> >> appropriate? |
17 |
> > |
18 |
> > Modulo the question "when should you use $ROOT over $EPREFIX"... |
19 |
> > |
20 |
> > * the chrome-binary-plugins ebuilds use it in src_install. |
21 |
> |
22 |
> This is quite obviously wrong. I happen to maintain that ebuild, so I |
23 |
> just fixed. |
24 |
> |
25 |
> > * dmraid does |
26 |
> > |
27 |
> > einfo "Appending pkg.m4 from system to aclocal.m4" |
28 |
> > cat "${ROOT}"/usr/share/aclocal/pkg.m4 >>"${S}"/aclocal.m4 || |
29 |
> > \ die "Could not append pkg.m4 |
30 |
> |
31 |
> This should be one of two things: |
32 |
> |
33 |
> cat /usr/share/aclocal/pkg.m4 |
34 |
> |
35 |
> Or, if prefix support is desired: |
36 |
> |
37 |
> cat "${EPREFIX}"/usr/share/aclocal/pkg.m4 |
38 |
> |
39 |
> > Both of those look like EPREFIX candidates to me, but they're not |
40 |
> > obviously wrong, either. Maybe it made sense in EAPI <= 3. |
41 |
> > |
42 |
> > Anywhere that you need addpredict() it also seems reasonable. The |
43 |
> > v4l-dvb-saa716x ebuilds use "${ROOT}/usr/src/linux/" where EPREFIX |
44 |
> > would not be a good replacement. |
45 |
> |
46 |
> Nah, usually addpredict is dealing with stuff in the system that is |
47 |
> performing the build. Sandboxed phases should never be looking at |
48 |
> ROOT. |
49 |
> |
50 |
> Those ebuilds should probably do addpredict /usr/src/linux instead. |
51 |
> |
52 |
> > |
53 |
> > Something needs to be fixed, though: you're right that the PMS |
54 |
> > limits ROOT to pkg_*. Who knew? If we want to be serious about |
55 |
> > banning ROOT in src_*, we should add a repoman error. |
56 |
> |
57 |
> Based on my own understanding of the ROOT variable, its use in src |
58 |
> functions is always nonsensical, especially when you consider binpkgs. |
59 |
> A binpkg can be installed with a ROOT value that is completely |
60 |
> different from its value when the package is being compiled. |
61 |
> |
62 |
> To put it another way, in src functions, ROOT could/should always be |
63 |
> "/". The real value of ROOT isn't determined until merge time. |
64 |
> |
65 |
> I agree, repoman should be catching this stuff. |
66 |
> |
67 |
|
68 |
Then Please contribute some test ebuilds for the gen-b0rk repo to test |
69 |
repoman or any other Q/A apps with. If they fail to detect the test |
70 |
ebuilds, it will give us something to use to help trace the code errors. |
71 |
It'll also make for a much better testing system overall for any app |
72 |
performing any type of Q/A on ebuilds. |
73 |
|
74 |
|
75 |
-- |
76 |
Brian Dolbec <dolsen> |