Multi-layer hierarchical profile layout with mix-ins
This page is a work in progress by MGorny (talk | contribs). Treat its contents with caution.
The profile layout is based on a number of hierarchical layers followed by a mix-in layer. Each of the hierarchical layers defines a number of profile variants. For example, the profile tree could define the following layers (with variants listed):
- system layer (linux, bsd, …),
- arch layer (x86, ppc, …).
All profile variants are exclusive. That is, the user must always choose exactly one variant in each hierarchical layer.
The layers are ordered, and the selected profiles are applied in the order of layers. The profiles in following layers may interact with the layers preceding them in two manners:
- via excludes/conflicts: for example, the bsd system may exclude the ppc arch. In this case, the choice of bsd system makes it disallowed to select ppc, and possibly hides the choice.
- via profile subvariants. Subvariants are subprofiles that are used instead of the main profile when a particular profile was selected in preceding layer. For example, if x86 defines a linux subvariant, it is used when linux system is combined with x86 arch.
It is important that subvariants are transparent to the user. In particular, the system tools (eselect profile update?) need to be able to transparently switch to another profile subvariant if the current subvariant is removed or a better-matching subvariant is introduced.
All of the hierarchical layers are followed by a mix-in layer. The mix-in layer represents a inclusive tree of profiles. The user may enable any number of mix-ins, as long as they do not collide with the selected hierarchical profiles or other mix-ins.
Each mix-in may have three specific properties:
- collisions with hierarchical profiles. In this case, a particular choice of hierarchical profile makes it impossible to enable a particular mix-in. The relevant mix-ins may be hidden from the user's choice.
- Collisions with other mix-ins. In this case, a choice of colliding mix-in makes it impossible to select the mix-in in question without deselecting the other. The UI may provide an ability to automatically deselect colliding mix-ins.
- Dependencies on other mix-ins (inheritance). In this case, a choice of mix-in implies loading all required (parent) mix-ins. The UI should highlight the mix-ins that are loaded automatically.
Necessary tool changes
Package Managers (core)
The layout can successfully be implemented using current profile handling code in Package Managers. It is only necessary for an external tool (eselect profile) to maintain a custom make.profile directory, with parent file referencing all the enabled profiles.
The eselect module for profile selection needs to be rewritten completely. In particular, the module needs to:
- support discovery of profile layers and variants,
- allow selecting hierarchical profile variants,
- allow enabling and disabling mix-ins,
- process profile collision specifications (and dependencies, as necessary),
- support discovery and choice of sub-variants.
Repoman needs to be updated to handle the new profile structure. In particular it needs to:
- support discovery of profiles layers and variants,
- support testing packages against combinations of profiles.
TODO: define directory layout for layers, profiles, sub-variants
TODO: define profile discovery or description file
The profile variant inheritance is established using parent files. The parent file specifies all profile directories the current profile inherits. Those directories may correspond to available profile variants or non-public profile directories (not listed in eselect profile list, used purely for inheritance).
In mix-in profiles, eselect profile can trace parent inheritance to highlight implicitly enabled profiles appropriately.
TODO: define profile collision format
Gentoo profile structure