| 1 |
On 07/02/14 14:10, Rich Freeman wrote: |
| 2 |
> On Wed, Jul 2, 2014 at 1:54 PM, Michał Górny <mgorny@g.o> wrote: |
| 3 |
>> I don't feel like we ought to vote on something like this without |
| 4 |
>> understanding most of the current profiles. And I'm afraid there are |
| 5 |
>> only few people who have any idea about the current profile |
| 6 |
>> structure... |
| 7 |
> No argument there. |
| 8 |
> |
| 9 |
> We may very well still end up with something hierarchical, but we can |
| 10 |
> at least limit that to the parts of the profile where it matters. |
| 11 |
> Maybe x86/BSD and amd64/Linux and amd64/Linux-hardened need to be |
| 12 |
> interdependent. However, that still gets rid of need to deal with |
| 13 |
> desktop environments, init systems, arguments over what belongs in |
| 14 |
> @system, and so on. We could have a blocker mechanism to keep people |
| 15 |
> from mixing systemd with BSD, or we could just let people shoot |
| 16 |
> themselves in the foot. |
| 17 |
> |
| 18 |
> Sounds like a good time to start reverse engineering the profiles... |
| 19 |
> |
| 20 |
> Rich |
| 21 |
> |
| 22 |
|
| 23 |
The way the profiles stack via the parent file makes them difficult to |
| 24 |
work with if they get to any significant depth. Here, for example, is |
| 25 |
the stacking for default/linux/mips/13.0/mipsel/multilib/n32 |
| 26 |
|
| 27 |
/usr/portage/profiles/base |
| 28 |
/usr/portage/profiles/default/linux |
| 29 |
*/usr/portage/profiles/arch/base |
| 30 |
*/usr/portage/profiles/arch/mips |
| 31 |
*/usr/portage/profiles/default/linux/mips |
| 32 |
/usr/portage/profiles/releases |
| 33 |
/usr/portage/profiles/releases/13.0 |
| 34 |
/usr/portage/profiles/default/linux/mips/13.0 |
| 35 |
*/usr/portage/profiles/arch/base |
| 36 |
*/usr/portage/profiles/arch/mips |
| 37 |
*/usr/portage/profiles/arch/mips/mipsel |
| 38 |
/usr/portage/profiles/default/linux/mips/13.0/mipsel |
| 39 |
*/usr/portage/profiles/arch/base |
| 40 |
*/usr/portage/profiles/arch/mips |
| 41 |
*/usr/portage/profiles/arch/mips/mipsel |
| 42 |
/usr/portage/profiles/arch/mips/mipsel/mips64el |
| 43 |
/usr/portage/profiles/features/multilib |
| 44 |
/usr/portage/profiles/arch/mips/mipsel/mips64el/multilib |
| 45 |
/usr/portage/profiles/arch/mips/mipsel/mips64el/multilib/n32 |
| 46 |
/usr/portage/profiles/default/linux/mips/13.0/mipsel/multilib/n32 |
| 47 |
|
| 48 |
|
| 49 |
I put asterisks there to point out a pattern that gets pulled in |
| 50 |
repeatedly. Sometimes this isn't a problem but sometimes this leads to |
| 51 |
asserting something, then reverting it, then asserting it again. In the |
| 52 |
ancient selinux profiles (circa 2009) this meant you couldn't have a |
| 53 |
no-mutlilib amd64 system. Shallow profiles avoid this. Also "features" |
| 54 |
avoid this (the closest thing we have to mix-ins) provided they operate |
| 55 |
on a set of flags/packages orthogonal to the rest of the stack. You |
| 56 |
then have shallow base and you can add as many features as you like in, |
| 57 |
in any order, confident that one will not clobber stuff from another |
| 58 |
since each feature is well separated. |
| 59 |
|
| 60 |
-- |
| 61 |
Anthony G. Basile, Ph.D. |
| 62 |
Gentoo Linux Developer [Hardened] |
| 63 |
E-Mail : blueness@g.o |
| 64 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
| 65 |
GnuPG ID : F52D4BBA |
Archives