1 |
On Mon, 1 Oct 2018 08:19:29 -0700 |
2 |
Zac Medico <zmedico@g.o> wrote: |
3 |
|
4 |
> Hi all, |
5 |
> |
6 |
> The ~arch version of portage hs a new QA check that reports installation |
7 |
> of files outside of directories that have been whitelisted [1]. The |
8 |
> current whitelist includes: |
9 |
> |
10 |
> directories common to / and /usr |
11 |
> ================================ |
12 |
> bin lib lib32 lib64 libx32 sbin |
13 |
> |
14 |
> top level directories |
15 |
> ================================ |
16 |
> boot dev etc opt srv usr var |
17 |
> |
18 |
> /usr level directories |
19 |
> ================================ |
20 |
> include libexec share src |
21 |
> |
22 |
> /usr/share/doc level directories |
23 |
> ================================ |
24 |
> /usr/share/doc/${PF} |
25 |
|
26 |
As this will break existing ebuilds I'd suggest guarding it against |
27 |
next EAPI. Out of top of by head the change will break at least |
28 |
crossdev outright. At least for two reasons: |
29 |
1. building a gcc cross-compiler usually refers to $SYSROOT/sys-include. |
30 |
'git grep sys-include' will show a bunch of ebuilds that create that |
31 |
symlinks outside the space. |
32 |
2. cross-building target libc is currently done on the host's emerge |
33 |
and installs into /usr/$CTARGET/. |
34 |
|
35 |
I think whitelist would be able to cover these use cases as they are |
36 |
a function of ${CTARGET} (or $CATEGORY) value. |
37 |
|
38 |
-- |
39 |
|
40 |
Sergei |