| 1 |
Hi everyone, |
| 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 |
-- Ruud |
Archives