82 lines
3.3 KiB
HTML
82 lines
3.3 KiB
HTML
<!-- vim: set tw=120 ft=html sw=4 sts=4 et : -->
|
|
|
|
<h1>Sets</h1>
|
|
|
|
<p>A set is a collection of package dependency specifications.</p>
|
|
|
|
<h2>Built-in Sets</h2>
|
|
|
|
<p>The following sets are always available:</p>
|
|
|
|
<dl>
|
|
<dt><code>system</code></dt>
|
|
<dd>Defined by repositories, system consists of core packages that make up a basic system.</dd>
|
|
|
|
<dt><code>world</code></dt>
|
|
<dd>Consists of the system set, plus all packages that have been installed as targets (as opposed to merely pulled
|
|
in as dependencies of a target).</dd>
|
|
|
|
<dt><code>installed-packages</code></dt>
|
|
<dd>The names of all installed packages.</dd>
|
|
|
|
<dt><code>installed-slots</code></dt>
|
|
<dd>The names plus slots of all installed packages.</dd>
|
|
|
|
<dt><code>security</code></dt>
|
|
<dd>The set of upgrades which must be performed to resolve security holes.</dd>
|
|
|
|
<dt><code>insecurity</code></dt>
|
|
<dd>The set of insecure packages (mostly for internal use).</dd>
|
|
|
|
<dt><code>nothing</code></dt>
|
|
<dd>An empty set.</dd>
|
|
</dl>
|
|
|
|
<p>Some sets, such as <code>system</code>, are made by combining sets from multiple repositories. For these sets, the
|
|
parts of the set defined by each individual repository can be accessed using <code>setname::reponame</code>.</p>
|
|
|
|
<h2>User Defined Sets</h2>
|
|
|
|
###PALUDISENVIRONMENTONLY###
|
|
|
|
<p>When using the Paludis environment, the user can create their own sets. A set named <code>foo</code> is defined in
|
|
the file <code>foo.conf</code>, which is a standard configuration file, or in the file <code>foo.bash</code>,
|
|
which is a dynamic standard configuration file. Sets may be specified in any of the following directories:</p>
|
|
|
|
<ul>
|
|
<li><code><em>confdir</em>/sets/</code>, where
|
|
<code><em>confdir</em></code> is the directory in which <code>use.conf</code>
|
|
et al. reside.</li>
|
|
|
|
<li><code><em>DATADIR</em>/paludis/sets/</code>. On most
|
|
systems, <code><em>DATADIR</em></code> is <code>/usr/share</code>.</li>
|
|
|
|
<li><code><em>LIBEXECDIR</em>/paludis/sets/</code>. On most
|
|
systems, <code><em>LIBEXECDIR</em></code> is <code>/usr/libexec</code>.</li>
|
|
</ul>
|
|
|
|
<div class="note">
|
|
<p>Overriding built-in sets in this manner is not recommended. Strange things will happen.</p>
|
|
</div>
|
|
|
|
<p>Each line in a user set file consists of an operator, followed by whitespace, followed by a package dependency
|
|
specification or, for some operators, a set name. Permitted operators are:</p>
|
|
|
|
<dl>
|
|
<dt><code>*</code></dt>
|
|
<dd>Indicates that the specification or set name is part of the set.</dd>
|
|
|
|
<dt><code>?</code></dt>
|
|
<dd>Indicates that the specification is part of the set if and only if a package whose name is equal to the name
|
|
part of the specification is installed. May not be used with a set name.</dd>
|
|
|
|
<dt><code>?:</code></dt>
|
|
<dd>Like <code>?</code>, but considers the slot part of the specification (if any) in addition to the name part.</dd>
|
|
</dl>
|
|
|
|
<p>If the set <code>foo</code> exists and is not a builtin set, the special set <code>foo*</code> is automatically
|
|
generated by Paludis. The <code>foo*</code> set is like the <code>foo</code> set, except that it behaves as if every
|
|
operator is a <code>*</code>. In addition, any set names inside that set are treated as if they were
|
|
<code>setname*</code>, so that the operator behaviour override is recursive.</p>
|
|
|