1 |
Ruud Koolen <redlizard@g.o> writes: |
2 |
|
3 |
> I am writing profiles for prefix-libc, and it is clear that the great majority |
4 |
> of clauses in the existing prefix base profile apply to prefix-libc in |
5 |
> exactly the same way for exactly the same reasons; programs or features that |
6 |
> need root, or do something hardware-related, or kernel-related, or |
7 |
> boot-related need the same masks/patches applying to them in prefix-libc as |
8 |
> they do in regular prefix. In fact, about the only stuff in the regular |
9 |
> prefix profile that would NOT apply to prefix-libc is most stuff related to |
10 |
> the toolchain (which prefix-libc solves in a different way than regular |
11 |
> prefix) or specific to prefix arches such as darwin. |
12 |
> |
13 |
> To avoid maintaining two copies of mostly the same profile, I am planning to |
14 |
> factor out the shared part (i.e. most of the present profile) into a feature |
15 |
> profile, profiles/features/prefix, which will contain a bunch of clauses that |
16 |
> can be added to arbitrary profiles to configure prefix support; both the |
17 |
> existing prefix profile, and the new prefix-libc profiles, will inherit this |
18 |
> feature profile. As a neat side effect, this construction opens up the way to |
19 |
> supporting more flexible prefix profile configurations: for example, with |
20 |
> prefix support a feature profile, there would be nothing stopping someone |
21 |
> from combining prefix with hardened to make a hardened prefix, which is the |
22 |
> sort of thing that just isn't possible with the current setup. |
23 |
> |
24 |
> Under profiles/features/prefix, I will then create two feature subprofiles, |
25 |
> profiles/features/prefix/rpath and profiles/features/prefix/standalone, to |
26 |
> create the additional profile parts that enable the toolchain hacks for the |
27 |
> two prefix variants; both these subprofiles inherit profiles/features/prefix, |
28 |
> and any prefix profile should inherit either of those subprofiles. |
29 |
> |
30 |
> With this system, the profiles/prefix base profile should be almost empty; |
31 |
> almost, but not quite. What remains there is everything specific to prefix |
32 |
> architectures such as darwin. profiles/prefix will be the base profile for |
33 |
> all prefix-specific architectures; it will inherit base and |
34 |
> features/prefix/rpath, and add clauses that mask linux-specific features. |
35 |
> Only the non-linux (and perhaps, non-freebsd) profiles will inherit this; the |
36 |
> linux profiles will inherit profiles/default/linux/* instead, just like they |
37 |
> do now, as well as features/prefix/rpath. |
38 |
> |
39 |
> Summarizing, in the current system we have profiles/prefix/linux/* profiles |
40 |
> inheriting profiles/default/linux/* and profiles/prefix, and |
41 |
> profiles/prefix/nonlinux/* profiles inheriting profiles/base and |
42 |
> profiles/prefix; with my changes, we will have profiles/prefix/linux/* |
43 |
> profiles inheriting profiles/default/linux/* and |
44 |
> profiles/features/prefix/rpath, profiles/prefix/nonlinux/* profiles |
45 |
> inheriting profiles/prefix, and profiles/prefix inheriting profiles/base and |
46 |
> profiles/features/prefix/rpath. And of course, there will be the new |
47 |
> prefix-libc profiles inheriting profiles/features/prefix/standalone, but the |
48 |
> details of those are outside the scope of this discussion. |
49 |
> |
50 |
> What are your thoughts on this? I have implemented and tested this change and |
51 |
> it seems to work out as expected. If no objections arise, I will commit this |
52 |
> in a few days. |
53 |
|
54 |
Nice sum up. Fine with me. |
55 |
|
56 |
If you are 100% sure that the outcome rpath profile makes no difference |
57 |
to the outside, i.e. no regression is ever possible, I think you could |
58 |
commit the change right away. |
59 |
|
60 |
The refactorization design has been discussed long before and we had |
61 |
consensus at that time. |
62 |
|
63 |
Cheers, |
64 |
Benda |