Difference between revisions of "Portage Profiles"

Revision as of 20:12, 1 January 2011

Gentoo Initialization

Gentoo profile initialization has been documented in this GitHub commit, and describes how Gentoo's Portage finds and processes profiles. Funtoo Linux will be making some changes to this algorithm, but first things first -- document the existing functionality. Basically, Gentoo's Portage looks for profiles using this algorithm:

1. Does /etc/make.profile exist? If so, it defines the primary profile.
2. If not, does /etc/portage/make.profile exist? If so, it defines the primary profile.
3. Recursively process the parent file found in the primary profile to build a list of all cascading profiles
4. if /etc/portage/profile exists, it is a user-defined profile - tack it to the end of our profile list so it can modify anything in the cascading profiles.

Here is a more detailed description of the steps:

1. Look for a profile directory/symlink at /etc/make.profile, if one exists, use this as the main profile directory.
2. If /etc/make.profile doesn't exist, use /etc/portage/make.profile as a back-up location if it exists.
3. If neither location exists, then a main profile directory doesn't exist and is undefined (None)

Using the main profile directory/symlink found above, the LocationsManager._addProfile() recursive function will be called that will create a list of all cascading profiles. This works by looking for a parent file in the profile directory. If this file exists, then each line is treated as a relative path and used to modify the path to the current profile, pointing to a "parent" profile that this particular profile modifies. There can be more than one parent, one per line. The first line in the parent file is the highest-priority parent.

Once this list is created, the code checks to see if /etc/portage/profile directory exists. If it does, it is tacked at the end of the cascading profile list, meaning that it is evaluated last and this user-defined profile has the ability to modify any of the cascading profile settings. It provides an ideal hook point for a user-defined profile that can tweak anything the user wants to modify in the profile.

Proposed Funtoo Changes

The current Portage profile functionality is a bit too complex, and is also missing some features that are needed for the funtoo-1.0 profile. The proposed changes here are designed to address these deficiencies, and are subject to change as the impact of these design changes are considered, and their elegance or ugliness is considered as well:

1. Deprecate /etc/make.profile symlink
2. Deprecate /etc/portage/make.profile symlink
3. Deprecate /etc/portage/profile directory
4. Add /etc/portage/profile.head as the master profile - intended to be a directory, not a symlink.
5. Add /etc/portage/profile.tail to replace /etc/portage/profile - functionally identical.
6. Add support for absolute paths in cascading profile parent files, to be interpreted as relative to the root of PORTDIR/profiles
7. Update eselect profile to deal with all this elegantly.

The way this system would be used is that /etc/portage/profile.head/parent would be a file where a user would set their master profile(s). Absolute paths would be used to define profiles that are relative to PORTDIR/profiles (see change 6 above.) Since parent supports more than one profile, it would now be possible for users to set more than one parent profile, so they could set it to something that looks like this:

/funtoo/1.0/linux/gnu/amd64
/funtoo/1.0/linux/flavor/server

This additional functionality would allow the simplification of the funtoo-1.0 profile structure since the various "flavors" of systems would not need to be replicated within each architecture's profile. It would also clean up how profiles are set using Funtoo Linux. To me, this approach is much better and the profile.head and profile.tail names are much easier to understand than make.profile and profile.

This functionality could be implemented so that a fallback to the classic Gentoo functionality is preserved (for a time) to allow for migration to the new profile scheme.

Alternate Approach - Mega-Unification

Suggested on the funtoo-dev mailing list, this proposal goes like this. There is a lot of duplication and unnecessary complexity in the Portage configuration directories, so the original Funtoo proposal may not have gone far enough in refactoring the layout. Basically, we can treat /etc/portage as the official Portage profile, and the user updates parents to specify parent profiles. This is how profiles are specified. /etc/make.conf can be replaced with make.defaults inside the /etc/portage directory, so that it follows the profile convention. Basically, this would merge /etc/portage/profile into /etc/portage, and also allow /etc/make.profile to be deprecated and replaced with /etc/portage/parent.

Funtoo Considerations

Here are some other things that might be worth considering:

1. Overlay-aware profiles - should "/" be relative to $PORTDIR/profiles or should there be something more to allow repo-specific settings? Could be nice. Maybe support "foo:/bar/oni" to refer to the "/bar/oni" profile in the "foo" repository.
2. since we are re-organizing things, move /etc/make.conf to /etc/portage/make.conf or /etc/portage/portage.conf.
3. likewise, move /etc/make.globals to /etc/portage/make.globals or /etc/portage/portage.globals.