Package Set Configuration
sets.conf locations
There are multiple locations where portage looks for set configuration
files, which are usually named sets.conf. Not all
of these locations have to contain a sets.conf, missing files are simply
ignored.
At first it looks for the default configuration in
/usr/share/portage/config.
The default config includes sets that are expected on all systems and
often critical for normal operation, like world,
system or security.
After that it will read repository specific configurations from
PORTDIR and PORTDIR_OVERLAYthat might
include definitions of sets included in the repository.
Finally a system-specific set configuration may reside in
/etc/portage to either define additional sets or
alter the default and repository sets.
sets.conf Syntax
Unlike other Portage configuration files sets.conf
uses Pythons ConfigParser module, which implements
the syntax usually found in .ini files. At it's core it allows various
named sections that each can contain any number of key-value pairs, see
the Python documentation
for the full details.
In a sets.conf file, a section can define either a
single package set, or a complete class of sets. These cases are handled
in different ways, and will be explained in detail in the following sections.
Single Set Configuration
The configuration of a single set can be very simple as in most cases
it only requires a single option class to be
complete Technically the class option
isn't stricly required, but it should always be used as the default
handler might be changed in future versions.
That option defines which handler class should be used to
create the set. Another universal option available for single sets is
name, however it's usually not needed as the name
of the set is generated from the section name if name
is missing. Some handler classes might require additional
options for their configuration, these will be covered later in
this chapter.
Here are a few examples for single sets taken from the default
configuration file:
# The classic world set
[world]
class = portage.sets.files.WorldSet
# The classic system set
[system]
class = portage.sets.profiles.PackagesSystemSet
Multi Set Configuration
As configuring each single set manually could be quite annoying if
you want many sets with the same options Portage also allows to
define whole classes of sets in a single section. Like with single
sets each section still requires the class option,
but to indicate that the section should generate multiple sets it's
also necessary to set the multiset option to
true.
As it doesn't make much sense to specify a single name for multiple sets
the name option isn't available for multiset sections.
Most handler classes will have a reasonable default for generating names,
and usually you can (but don't have to) set the
name_pattern option to change the naming rules. That
option generally has to include a (handler-specific) placeholder that
will be replaced with a unique identifier (e.g. for category sets the
category name). As with single sets handler classes might require and/or
support additional options, these will be discussed later.
Some examples for multiset configurations:
# generate a set for each file in /etc/portage/sets
# this section is also in the default configuration
[user sets]
class = portage.sets.files.StaticFileSet
multiset = true
directory = /etc/portage/sets
# Generate a set for each category that includes all installed packages
# from that category. The sets will be named <category>/*
[installed category packages]
class = portage.sets.dbapi.CategorySet
multiset = true
repository = vartree
name_pattern = $category/*
Available Set Handler Classes
The following sections contain the available handler classes that can be
used for the class option in
sets.conf, together with a description about required
and optional configuration options for single and multi set configurations.
Note that not all classes support both configuration styles.
portage.sets.files.StaticFileSet
This class implements a simple file based package set. All atoms from
configured file are used to form the set, and currently only simple and
versioned atoms are supported (no use conditionals or any-of constructs).
For descriptive purposes the file can be accompanied by a file with the
same name plus a .metadata suffix which can contain
metadata sections for description, author, location and so on. Each section
has the form key: value where value
can contain multiple lines. Therefore sections have to be separated by
blank lines. For example:
description: This is a somewhat
longer description than usual. So it
needs more than one line.
homepage: http://www.foobar.org
author: John Doe <john@doe.com>
Single Set Configuration
In a single set configuration this class supports the following options:
filename: Required. Specifies the path to the file
that should be used for the package set.
Multi Set Configuration
In a multi set configuration this class supports the following options:
directory: Optional, defaults to
/etc/portage/sets. Specifies the path to a directory
containing package set files. For each file (excluding metadata files) in
that location a separate package set is created.
name_pattern: Optional, defaults to
sets/$name. This describes the naming pattern
to be used for creating the sets. It must contain either
$name or ${name}, which
will be replaced by the filename (without any directory components).
portage.sets.files.ConfigFileSet
Similar to StaticFileSet, but uses Portage configuration files.
Namely it can work with package.use,
package.keywords, package.mask
and package.unmask. It does not support
.metadata files, but ignores the extra data (like
USE flags or keywords) typically found in those files.
Single Set Configuration
In a single set configuration this class supports the following options:
filename: See
StaticFileSet
Multi Set Configuration
In a multi set configuration this class supprts the following options:
directory: Optional, defaults to
/etc/portage. Specifies the path to a directory
containing one or more of the following portage configuration files:
package.use, package.keywords,
package.mask or package.unmask.
No other files in that directory will be used.
name_pattern: Optional, defaults to
sets/package_$suffix. This describes the naming
pattern to be used for creating the sets. It must contain either
$suffix or ${suffix},
which will be replaced by the file suffix (e.g.
use or mask).
portage.sets.files.WorldSet
portage.sets.profiles.PackagesSystemSet
portage.sets.security.SecuritySet
portage.sets.security.NewGlsaSet
portage.sets.security.NewAffectedSet
portage.sets.security.AffectedSet
portage.sets.shell.CommandOutputSet
portage.sets.dbapi.CategorySet
portage.sets.dbapi.EverythingSet