Custom Profiles

Introduction
This guide will show you how to create a custom profile in an overlay, based on an official profile. It is designed to provide a simple, easy to follow overview, but does not go into any detail about the allowed contents of profiles. Further information on profiles can be found in the portage and emerge documentation and man pages.

Reasoning
While could be used, it is additionally used for machine/setup specific and package generated data (eg. bashrc, savedconfig). Symlinks cannot be used for /etc/portage/package.*, which prevents storing some of the information in another location an linking it. It also requires extra sync'ing in addition to the overlay that is normally used anyway.

Simple Profile Setup
This guide will assume you have a basic overlay already setup and added to PORTDIR_OVERLAY.

First, ensure that your overlay has a repository name. The repository name is the content of. For example, to give the repository the name example-repo, run the following from your overlay root:

Next we create the profile. In this case I'm calling the profile :

Specify the eapi which the profile files use:

Setup a special marker so that we know the custom profile is being pulled in:

Finally we select the profile. While it is possible for profiles in overlays to inherit from the main tree, the following method is simpler and less error prone. These instructions assume that your PORTDIR is and your overlay is at.

The file is evaluated from top to bottom, so in this case portage will first look at the default/linux/x86/10.0 profile, then our new default/linux/x86/10.0/example profile.

Testing the Profile
We can now check that portage is looking at our new profile using the marker we added earlier by running:

The first change to note is that the profile name has disappeared from the first line of the output: Portage 2.2_rc48 (unavailable, gcc-4.3.4, glibc-2.9_p20081201-r2, 2.6.31-xen-r4 x86_64)

The second change is that our marker appears in the list of environment variables: CUSTOM_PROFILE="yes"

Package.keywords
Inside a profile, package.keywords acts differently to. specifies the keywords you want portage to accept for the package, while the in a profile specifies the keywords that a package has.

To take a simple example, if you want portage 2.2, which at the time of writing is, in you would enter: <sys-apps/portage-2.3 ~x86

However, to achieve the same with in a profile, you need to use: <sys-apps/portage-2.3 x86

Further explanation and discussion can be found on. A feature request for a file in the same format as  exists as

Sets
Sets cannot be handled on a per-profile basis, so the only solution here is to choose a naming scheme that will not conflict. For example, I prefix all my set names with "ajb-".

Sets can be set up in the overlay, using in the root of the overlay (for example, ). You can store the set contents files in the overlay, then refer to them using the special repository syntax. For example, where example-repo is the repository name specified in : [ajb-mail-server] class = portage.sets.files.StaticFileSet filename = ${repository:example-repo}/sets/mail-server