Re: [gentoo-alt] Refactoring prefix profiles

Ruud Koolen <redlizard@g.o> writes:

> I am writing profiles for prefix-libc, and it is clear that the great majority
> of clauses in the existing prefix base profile apply to prefix-libc in
> exactly the same way for exactly the same reasons; programs or features that
> need root, or do something hardware-related, or kernel-related, or
> boot-related need the same masks/patches applying to them in prefix-libc as
> they do in regular prefix. In fact, about the only stuff in the regular
> prefix profile that would NOT apply to prefix-libc is most stuff related to
> the toolchain (which prefix-libc solves in a different way than regular
> prefix) or specific to prefix arches such as darwin.
>
> To avoid maintaining two copies of mostly the same profile, I am planning to
> factor out the shared part (i.e. most of the present profile) into a feature
> profile, profiles/features/prefix, which will contain a bunch of clauses that
> can be added to arbitrary profiles to configure prefix support; both the
> existing prefix profile, and the new prefix-libc profiles, will inherit this
> feature profile. As a neat side effect, this construction opens up the way to
> supporting more flexible prefix profile configurations: for example, with
> prefix support a feature profile, there would be nothing stopping someone
> from combining prefix with hardened to make a hardened prefix, which is the
> sort of thing that just isn't possible with the current setup.
>
> Under profiles/features/prefix, I will then create two feature subprofiles,
> profiles/features/prefix/rpath and profiles/features/prefix/standalone, to
> create the additional profile parts that enable the toolchain hacks for the
> two prefix variants; both these subprofiles inherit profiles/features/prefix,
> and any prefix profile should inherit either of those subprofiles.
>
> With this system, the profiles/prefix base profile should be almost empty;
> almost, but not quite. What remains there is everything specific to prefix
> architectures such as darwin. profiles/prefix will be the base profile for
> all prefix-specific architectures; it will inherit base and
> features/prefix/rpath, and add clauses that mask linux-specific features.
> Only the non-linux (and perhaps, non-freebsd) profiles will inherit this; the
> linux profiles will inherit profiles/default/linux/* instead, just like they
> do now, as well as features/prefix/rpath.
>
> Summarizing, in the current system we have profiles/prefix/linux/* profiles
> inheriting profiles/default/linux/* and profiles/prefix, and
> profiles/prefix/nonlinux/* profiles inheriting profiles/base and
> profiles/prefix; with my changes, we will have profiles/prefix/linux/*
> profiles inheriting profiles/default/linux/* and
> profiles/features/prefix/rpath, profiles/prefix/nonlinux/* profiles
> inheriting profiles/prefix, and profiles/prefix inheriting profiles/base and
> profiles/features/prefix/rpath. And of course, there will be the new
> prefix-libc profiles inheriting profiles/features/prefix/standalone, but the
> details of those are outside the scope of this discussion.
>
> What are your thoughts on this? I have implemented and tested this change and
> it seems to work out as expected. If no objections arise, I will commit this
> in a few days.

Nice sum up. Fine with me.

If you are 100% sure that the outcome rpath profile makes no difference
to the outside, i.e. no regression is ever possible, I think you could
commit the change right away.

The refactorization design has been discussed long before and we had
consensus at that time.

Cheers,
Benda