This document explains the concept known to Paludis as a 'set', and describes the standard internal sets and how to create new sets.
Internally, a set is a name with an associated dependency-style specification. In most cases the dependency specification will be an 'all-of' collection of package dependencies, although this is not a hard restriction.
There are multiple origins for sets:
security. Repository classes may also provide a way for additional sets to be defined by the repository maintainer. If multiple repositories define a named set, the resulting set is all of these repository sets merged using an 'all-of' composite. The
worldsets automatically contain
securitysets always exist, even if no repositories nor the environment defines them.
Important: a set is a named collecion of dependency specifications, not a collection of packages.
PaludisEnvironment environment class allows user defined package sets via
text files. These should be named
setname.conf and placed in
confdir is the configuration directory
use.conf et al. reside. The format is as follows:
#. These, and blank lines, are ignored.
*should be used to mean "include this package dependency specification in the set".
?should be used to mean "include this package dependency specification in the set if and only if the package part of the specification is matched by an installed package". For example, the line
? >=app-editors/vim-7means requires
vim-7if and only if
app-editors/vim(any version) is already installed.
Most users will only have use for
In addition, dynamic sets are possible. These should use a
.bash extension instead
.conf, and when executed should output what would be valid content for a
Ebuild format repositories can supply their own sets. The
security sets are defined programmatically; other sets are defined by a file
sets/setname.conf, which should be in the format described for
user defined sets above.
Sets can currently be used as targets for
paludis --install and
They can also be used as the specification column in the