View file File name : ch-relationships.html Content : <!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.17.1: http://docutils.sourceforge.net/" /> <title>7. Declaring relationships between packages — Debian Policy Manual v4.6.0.1</title> <link rel="stylesheet" type="text/css" href="_static/pygments.css" /> <link rel="stylesheet" type="text/css" href="_static/nature.css" /> <script data-url_root="./" id="documentation_options" src="_static/documentation_options.js"></script> <script src="_static/jquery.js"></script> <script src="_static/underscore.js"></script> <script src="_static/doctools.js"></script> <link rel="index" title="Index" href="genindex.html" /> <link rel="search" title="Search" href="search.html" /> <link rel="next" title="8. Shared libraries" href="ch-sharedlibs.html" /> <link rel="prev" title="6. Package maintainer scripts and installation procedure" href="ch-maintainerscripts.html" /> </head><body> <div class="related" role="navigation" aria-label="related navigation"> <h3>Navigation</h3> <ul> <li class="right" style="margin-right: 10px"> <a href="genindex.html" title="General Index" accesskey="I">index</a></li> <li class="right" > <a href="ch-sharedlibs.html" title="8. Shared libraries" accesskey="N">next</a> |</li> <li class="right" > <a href="ch-maintainerscripts.html" title="6. Package maintainer scripts and installation procedure" accesskey="P">previous</a> |</li> <li class="nav-item nav-item-0"><a href="index.html">Debian Policy Manual v4.6.0.1</a> »</li> <li class="nav-item nav-item-this"><a href=""><span class="section-number">7. </span>Declaring relationships between packages</a></li> </ul> </div> <div class="document"> <div class="documentwrapper"> <div class="bodywrapper"> <div class="body" role="main"> <section id="declaring-relationships-between-packages"> <h1><span class="section-number">7. </span>Declaring relationships between packages<a class="headerlink" href="#declaring-relationships-between-packages" title="Permalink to this headline">¶</a></h1> <section id="syntax-of-relationship-fields"> <span id="s-depsyntax"></span><h2><span class="section-number">7.1. </span>Syntax of relationship fields<a class="headerlink" href="#syntax-of-relationship-fields" title="Permalink to this headline">¶</a></h2> <p>These fields all have a uniform syntax. They are a list of package names separated by commas.</p> <p>In the <code class="docutils literal notranslate"><span class="pre">Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Recommends</span></code>, <code class="docutils literal notranslate"><span class="pre">Suggests</span></code>, <code class="docutils literal notranslate"><span class="pre">Pre-Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends-Indep</span></code> and <code class="docutils literal notranslate"><span class="pre">Build-Depends-Arch</span></code> control fields of the package, which declare dependencies on other packages, the package names listed may also include lists of alternative package names, separated by vertical bar (pipe) symbols <code class="docutils literal notranslate"><span class="pre">|</span></code>. In such a case, that part of the dependency can be satisfied by any one of the alternative packages. <a class="footnote-reference brackets" href="#id8" id="id1">1</a></p> <p>All of the fields may restrict their applicability to particular versions of each named package. This is done in parentheses after each individual package name; the parentheses should contain a relation from the list below followed by a version number, in the format described in <a class="reference internal" href="ch-controlfields.html#s-f-version"><span class="std std-ref">Version</span></a>.</p> <p>The relations allowed are <code class="docutils literal notranslate"><span class="pre"><<</span></code>, <code class="docutils literal notranslate"><span class="pre"><=</span></code>, <code class="docutils literal notranslate"><span class="pre">=</span></code>, <code class="docutils literal notranslate"><span class="pre">>=</span></code> and <code class="docutils literal notranslate"><span class="pre">>></span></code> for strictly earlier, earlier or equal, exactly equal, later or equal and strictly later, respectively. The exception is the Provides field, for which only <code class="docutils literal notranslate"><span class="pre">=</span></code> is allowed. <a class="footnote-reference brackets" href="#id9" id="id2">2</a></p> <p>Whitespace may appear at any point in the version specification subject to the rules in <a class="reference internal" href="ch-controlfields.html#s-controlsyntax"><span class="std std-ref">Syntax of control files</span></a>, and must appear where it’s necessary to disambiguate; it is not otherwise significant. All of the relationship fields can only be folded in source package control files. For consistency and in case of future changes to <code class="docutils literal notranslate"><span class="pre">dpkg</span></code> it is recommended that a single space be used after a version relationship and before a version number; it is also conventional to put a single space after each comma, on either side of each vertical bar, and before each open parenthesis. When opening a continuation line in a relationship field, it is conventional to do so after a comma and before the space following that comma.</p> <p>For example, a list of dependencies might appear as:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Package</span><span class="p">:</span> <span class="n">mutt</span> <span class="n">Version</span><span class="p">:</span> <span class="mf">1.3</span><span class="o">.</span><span class="mi">17</span><span class="o">-</span><span class="mi">1</span> <span class="n">Depends</span><span class="p">:</span> <span class="n">libc6</span> <span class="p">(</span><span class="o">>=</span> <span class="mf">2.2</span><span class="o">.</span><span class="mi">1</span><span class="p">),</span> <span class="n">default</span><span class="o">-</span><span class="n">mta</span> <span class="o">|</span> <span class="n">mail</span><span class="o">-</span><span class="n">transport</span><span class="o">-</span><span class="n">agent</span> </pre></div> </div> <p>Relationships may be restricted to a certain set of architectures. This is indicated in brackets after each individual package name and the optional version specification. The brackets enclose a non-empty list of Debian architecture names in the format described in <a class="reference internal" href="ch-customized-programs.html#s-arch-spec"><span class="std std-ref">Architecture specification strings</span></a>, separated by whitespace. Exclamation marks may be prepended to each of the names. (It is not permitted for some names to be prepended with exclamation marks while others aren’t.)</p> <p>For build relationship fields (<code class="docutils literal notranslate"><span class="pre">Build-Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends-Indep</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends-Arch</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Conflicts</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Conflicts-Indep</span></code> and <code class="docutils literal notranslate"><span class="pre">Build-Conflicts-Arch</span></code>), if the current Debian host architecture is not in this list and there are no exclamation marks in the list, or it is in the list with a prepended exclamation mark, the package name and the associated version specification are ignored completely for the purposes of defining the relationships.</p> <p>For example:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span>Source: glibc Build-Depends-Indep: texinfo Build-Depends: kernel-headers-2.2.10 [!hurd-i386], hurd-dev [hurd-i386], gnumach-dev [hurd-i386] </pre></div> </div> <p>requires <code class="docutils literal notranslate"><span class="pre">kernel-headers-2.2.10</span></code> on all architectures other than hurd-i386 and requires <code class="docutils literal notranslate"><span class="pre">hurd-dev</span></code> and <code class="docutils literal notranslate"><span class="pre">gnumach-dev</span></code> only on hurd-i386. Here is another example showing multiple architectures separated by spaces:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Build</span><span class="o">-</span><span class="n">Depends</span><span class="p">:</span> <span class="n">libluajit5</span><span class="o">.</span><span class="mi">1</span><span class="o">-</span><span class="n">dev</span> <span class="p">[</span><span class="n">i386</span> <span class="n">amd64</span> <span class="n">kfreebsd</span><span class="o">-</span><span class="n">i386</span> <span class="n">armel</span> <span class="n">armhf</span> <span class="n">powerpc</span> <span class="n">mips</span><span class="p">],</span> <span class="n">liblua5</span><span class="o">.</span><span class="mi">1</span><span class="o">-</span><span class="n">dev</span> <span class="p">[</span><span class="n">hurd</span><span class="o">-</span><span class="n">i386</span> <span class="n">ia64</span> <span class="n">kfreebsd</span><span class="o">-</span><span class="n">amd64</span> <span class="n">s390x</span> <span class="n">sparc</span><span class="p">],</span> </pre></div> </div> <p>For binary relationship fields and the <code class="docutils literal notranslate"><span class="pre">Built-Using</span></code> field, the architecture restriction syntax is only supported in the source package control file <code class="docutils literal notranslate"><span class="pre">debian/control</span></code>. When the corresponding binary package control file is generated, the relationship will either be omitted or included without the architecture restriction based on the architecture of the binary package. This means that architecture restrictions must not be used in binary relationship fields for architecture-independent packages (<code class="docutils literal notranslate"><span class="pre">Architecture:</span> <span class="pre">all</span></code>).</p> <p>For example:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Depends</span><span class="p">:</span> <span class="n">foo</span> <span class="p">[</span><span class="n">i386</span><span class="p">],</span> <span class="n">bar</span> <span class="p">[</span><span class="n">amd64</span><span class="p">]</span> </pre></div> </div> <p>becomes <code class="docutils literal notranslate"><span class="pre">Depends:</span> <span class="pre">foo</span></code> when the package is built on the <code class="docutils literal notranslate"><span class="pre">i386</span></code> architecture, <code class="docutils literal notranslate"><span class="pre">Depends:</span> <span class="pre">bar</span></code> when the package is built on the <code class="docutils literal notranslate"><span class="pre">amd64</span></code> architecture, and omitted entirely in binary packages built on all other architectures.</p> <p>If the architecture-restricted dependency is part of a set of alternatives using <code class="docutils literal notranslate"><span class="pre">|</span></code>, that alternative is ignored completely on architectures that do not match the restriction. For example:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span>Build-Depends: foo [!i386] | bar [!amd64] </pre></div> </div> <p>is equivalent to <code class="docutils literal notranslate"><span class="pre">bar</span></code> on the <code class="docutils literal notranslate"><span class="pre">i386</span></code> architecture, to <code class="docutils literal notranslate"><span class="pre">foo</span></code> on the <code class="docutils literal notranslate"><span class="pre">amd64</span></code> architecture, and to <code class="docutils literal notranslate"><span class="pre">foo</span> <span class="pre">|</span> <span class="pre">bar</span></code> on all other architectures.</p> <p>Relationships may also be restricted to a certain set of architectures using architecture wildcards in the format described in <a class="reference internal" href="ch-customized-programs.html#s-arch-wildcard-spec"><span class="std std-ref">Architecture wildcards</span></a>. The syntax for declaring such restrictions is the same as declaring restrictions using a certain set of architectures without architecture wildcards. For example:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span>Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] </pre></div> </div> <p>is equivalent to <code class="docutils literal notranslate"><span class="pre">foo</span></code> on architectures using the Linux kernel and any cpu, <code class="docutils literal notranslate"><span class="pre">bar</span></code> on architectures using any kernel and an i386 cpu, and <code class="docutils literal notranslate"><span class="pre">baz</span></code> on any architecture using a kernel other than Linux.</p> <p>Note that the binary package relationship fields such as <code class="docutils literal notranslate"><span class="pre">Depends</span></code> appear in one of the binary package sections of the control file, whereas the build-time relationships such as <code class="docutils literal notranslate"><span class="pre">Build-Depends</span></code> appear in the source package section of the control file (which is the first section).</p> </section> <section id="binary-dependencies-depends-recommends-suggests-enhances-pre-depends"> <span id="s-binarydeps"></span><h2><span class="section-number">7.2. </span>Binary Dependencies - <code class="docutils literal notranslate"><span class="pre">Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Recommends</span></code>, <code class="docutils literal notranslate"><span class="pre">Suggests</span></code>, <code class="docutils literal notranslate"><span class="pre">Enhances</span></code>, <code class="docutils literal notranslate"><span class="pre">Pre-Depends</span></code><a class="headerlink" href="#binary-dependencies-depends-recommends-suggests-enhances-pre-depends" title="Permalink to this headline">¶</a></h2> <p>Packages can declare in their control file that they have certain relationships to other packages - for example, that they cannot be installed at the same time as certain other packages, and/or that they depend on the presence of others.</p> <p>This is done using the <code class="docutils literal notranslate"><span class="pre">Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Pre-Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Recommends</span></code>, <code class="docutils literal notranslate"><span class="pre">Suggests</span></code>, <code class="docutils literal notranslate"><span class="pre">Enhances</span></code>, <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> and <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code> control fields. <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> is described in <a class="reference internal" href="#s-breaks"><span class="std std-ref">Packages which break other packages - Breaks</span></a>, and <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code> is described in <a class="reference internal" href="#s-conflicts"><span class="std std-ref">Conflicting binary packages - Conflicts</span></a>. The rest are described below.</p> <p>These seven fields are used to declare a dependency relationship by one package on another. Except for <code class="docutils literal notranslate"><span class="pre">Enhances</span></code> and <code class="docutils literal notranslate"><span class="pre">Breaks</span></code>, they appear in the depending (binary) package’s control file. (<code class="docutils literal notranslate"><span class="pre">Enhances</span></code> appears in the recommending package’s control file, and <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> appears in the version of depended-on package which causes the named package to break).</p> <p>A <code class="docutils literal notranslate"><span class="pre">Depends</span></code> field takes effect <em>only</em> when a package is to be configured. It does not prevent a package being on the system in an unconfigured state while its dependencies are unsatisfied, and it is possible to replace a package whose dependencies are satisfied and which is properly installed with a different version whose dependencies are not and cannot be satisfied; when this is done the depending package will be left unconfigured (since attempts to configure it will give errors) and will not function properly. If it is necessary, a <code class="docutils literal notranslate"><span class="pre">Pre-Depends</span></code> field can be used, which has a partial effect even when a package is being unpacked, as explained in detail below. (The other three dependency fields, <code class="docutils literal notranslate"><span class="pre">Recommends</span></code>, <code class="docutils literal notranslate"><span class="pre">Suggests</span></code> and <code class="docutils literal notranslate"><span class="pre">Enhances</span></code>, are only used by the various front-ends to <code class="docutils literal notranslate"><span class="pre">dpkg</span></code> such as <code class="docutils literal notranslate"><span class="pre">apt-get</span></code>, <code class="docutils literal notranslate"><span class="pre">aptitude</span></code>, and <code class="docutils literal notranslate"><span class="pre">dselect</span></code>.)</p> <p>Since <code class="docutils literal notranslate"><span class="pre">Depends</span></code> only places requirements on the order in which packages are configured, packages in an installation run are usually all unpacked first and all configured later. <a class="footnote-reference brackets" href="#id10" id="id3">3</a></p> <p>If there is a circular dependency among packages being installed or removed, installation or removal order honoring the dependency order is impossible, requiring the dependency loop be broken at some point and the dependency requirements violated for at least one package. Packages involved in circular dependencies may not be able to rely on their dependencies being configured before they themselves are configured, depending on which side of the break of the circular dependency loop they happen to be on. If one of the packages in the loop has no <code class="docutils literal notranslate"><span class="pre">postinst</span></code> script, then the cycle will be broken at that package; this ensures that all <code class="docutils literal notranslate"><span class="pre">postinst</span></code> scripts are run with their dependencies properly configured if this is possible. Otherwise the breaking point is arbitrary. Packages should therefore avoid circular dependencies where possible, particularly if they have <code class="docutils literal notranslate"><span class="pre">postinst</span></code> scripts.</p> <p>The meaning of the five dependency fields is as follows:</p> <dl> <dt><code class="docutils literal notranslate"><span class="pre">Depends</span></code></dt><dd><p>This declares an absolute dependency. A package will not be configured unless all of the packages listed in its <code class="docutils literal notranslate"><span class="pre">Depends</span></code> field have been correctly configured (unless there is a circular dependency as described above).</p> <p>The <code class="docutils literal notranslate"><span class="pre">Depends</span></code> field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality.</p> <p>The <code class="docutils literal notranslate"><span class="pre">Depends</span></code> field should also be used if the <code class="docutils literal notranslate"><span class="pre">postinst</span></code> or <code class="docutils literal notranslate"><span class="pre">prerm</span></code> scripts require the depended-on package to be unpacked or configured in order to run. In the case of <code class="docutils literal notranslate"><span class="pre">postinst</span> <span class="pre">configure</span></code>, the depended-on packages will be unpacked and configured first. (If both packages are involved in a dependency loop, this might not work as expected; see the explanation a few paragraphs back.) In the case of <code class="docutils literal notranslate"><span class="pre">prerm</span></code> or other <code class="docutils literal notranslate"><span class="pre">postinst</span></code> actions, the package dependencies will normally be at least unpacked, but they may be only “Half-Installed” if a previous upgrade of the dependency failed.</p> <p>Finally, the <code class="docutils literal notranslate"><span class="pre">Depends</span></code> field should be used if the depended-on package is needed by the <code class="docutils literal notranslate"><span class="pre">postrm</span></code> script to fully clean up after the package removal. There is no guarantee that package dependencies will be available when <code class="docutils literal notranslate"><span class="pre">postrm</span></code> is run, but the depended-on package is more likely to be available if the package declares a dependency (particularly in the case of <code class="docutils literal notranslate"><span class="pre">postrm</span> <span class="pre">remove</span></code>). The <code class="docutils literal notranslate"><span class="pre">postrm</span></code> script must gracefully skip actions that require a dependency if that dependency isn’t available.</p> </dd> <dt><code class="docutils literal notranslate"><span class="pre">Recommends</span></code></dt><dd><p>This declares a strong, but not absolute, dependency.</p> <p>The <code class="docutils literal notranslate"><span class="pre">Recommends</span></code> field should list packages that would be found together with this one in all but unusual installations.</p> </dd> <dt><code class="docutils literal notranslate"><span class="pre">Suggests</span></code></dt><dd><p>This is used to declare that one package may be more useful with one or more others. Using this field tells the packaging system and the user that the listed packages are related to this one and can perhaps enhance its usefulness, but that installing this one without them is perfectly reasonable.</p> </dd> <dt><code class="docutils literal notranslate"><span class="pre">Enhances</span></code></dt><dd><p>This field is similar to Suggests but works in the opposite direction. It is used to declare that a package can enhance the functionality of another package.</p> </dd> <dt><code class="docutils literal notranslate"><span class="pre">Pre-Depends</span></code></dt><dd><p>This field is like <code class="docutils literal notranslate"><span class="pre">Depends</span></code>, except that it also forces <code class="docutils literal notranslate"><span class="pre">dpkg</span></code> to complete installation of the packages named before even starting the installation of the package which declares the pre-dependency, as follows:</p> <p>When a package declaring a pre-dependency is about to be <em>unpacked</em> the pre-dependency can be satisfied if the depended-on package is either fully configured, <em>or even if</em> the depended-on package(s) are only in the “Unpacked” or the “Half-Configured” state, provided that they have been configured correctly at some point in the past (and not removed or partially removed since). In this case, both the previously-configured and currently “Unpacked” or “Half-Configured” versions must satisfy any version clause in the <code class="docutils literal notranslate"><span class="pre">Pre-Depends</span></code> field.</p> <p>When the package declaring a pre-dependency is about to be <em>configured</em>, the pre-dependency will be treated as a normal <code class="docutils literal notranslate"><span class="pre">Depends</span></code>. It will be considered satisfied only if the depended-on package has been correctly configured. However, unlike with <code class="docutils literal notranslate"><span class="pre">Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Pre-Depends</span></code> does not permit circular dependencies to be broken. If a circular dependency is encountered while attempting to honor <code class="docutils literal notranslate"><span class="pre">Pre-Depends</span></code>, the installation will be aborted.</p> <p><code class="docutils literal notranslate"><span class="pre">Pre-Depends</span></code> are also required if the <code class="docutils literal notranslate"><span class="pre">preinst</span></code> script depends on the named package. It is best to avoid this situation if possible.</p> <p><code class="docutils literal notranslate"><span class="pre">Pre-Depends</span></code> should be used sparingly, preferably only by packages whose premature upgrade or installation would hamper the ability of the system to continue with any upgrade that might be in progress.</p> <p>You should not specify a <code class="docutils literal notranslate"><span class="pre">Pre-Depends</span></code> entry for a package before this has been discussed on the <code class="docutils literal notranslate"><span class="pre">debian-devel</span></code> mailing list and a consensus about doing that has been reached. See <a class="reference internal" href="ch-binary.html#s-dependencies"><span class="std std-ref">Dependencies</span></a>.</p> </dd> </dl> <p>When selecting which level of dependency to use you should consider how important the depended-on package is to the functionality of the one declaring the dependency. Some packages are composed of components of varying degrees of importance. Such a package should list using <code class="docutils literal notranslate"><span class="pre">Depends</span></code> the package(s) which are required by the more important components. The other components’ requirements may be mentioned as Suggestions or Recommendations, as appropriate to the components’ relative importance.</p> </section> <section id="packages-which-break-other-packages-breaks"> <span id="s-breaks"></span><h2><span class="section-number">7.3. </span>Packages which break other packages - <code class="docutils literal notranslate"><span class="pre">Breaks</span></code><a class="headerlink" href="#packages-which-break-other-packages-breaks" title="Permalink to this headline">¶</a></h2> <p>When one binary package declares that it breaks another, <code class="docutils literal notranslate"><span class="pre">dpkg</span></code> will refuse to allow the package which declares <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> to be unpacked unless the broken package is deconfigured first, and it will refuse to allow the broken package to be reconfigured.</p> <p>A package will not be regarded as causing breakage merely because its configuration files are still installed; it must be at least “Half-Installed”.</p> <p>A special exception is made for packages which declare that they break their own package name or a virtual package which they provide (see below): this does not count as a real breakage.</p> <p>Normally a <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> entry will have an “earlier than” version clause; such a <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> is introduced in the version of an (implicit or explicit) dependency which violates an assumption or reveals a bug in earlier versions of the broken package, or which takes over a file from earlier versions of the package named in <code class="docutils literal notranslate"><span class="pre">Breaks</span></code>. This use of <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> will inform higher-level package management tools that the broken package must be upgraded before the new one.</p> <p>If the breaking package also overwrites some files from the older package, it should use <code class="docutils literal notranslate"><span class="pre">Replaces</span></code> to ensure this goes smoothly. See <a class="reference internal" href="#s-replaces"><span class="std std-ref">Overwriting files and replacing packages - Replaces</span></a> for a full discussion of taking over files from other packages, including how to use <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> in those cases.</p> <p>Many of the cases where <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> should be used were previously handled with <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code> because <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> did not yet exist. Many <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code> fields should now be <code class="docutils literal notranslate"><span class="pre">Breaks</span></code>. See <a class="reference internal" href="#s-conflicts"><span class="std std-ref">Conflicting binary packages - Conflicts</span></a> for more information about the differences.</p> </section> <section id="conflicting-binary-packages-conflicts"> <span id="s-conflicts"></span><h2><span class="section-number">7.4. </span>Conflicting binary packages - <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code><a class="headerlink" href="#conflicting-binary-packages-conflicts" title="Permalink to this headline">¶</a></h2> <p>When one binary package declares a conflict with another using a <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code> field, <code class="docutils literal notranslate"><span class="pre">dpkg</span></code> will refuse to allow them to be unpacked on the system at the same time. This is a stronger restriction than <code class="docutils literal notranslate"><span class="pre">Breaks</span></code>, which prevents the broken package from being configured while the breaking package is in the “Unpacked” state but allows both packages to be unpacked at the same time.</p> <p>If one package is to be unpacked, the other must be removed first. If the package being unpacked is marked as replacing (see <a class="reference internal" href="#s-replaces"><span class="std std-ref">Overwriting files and replacing packages - Replaces</span></a>, but note that <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> should normally be used in this case) the one on the system, or the one on the system is marked as deselected, or both packages are marked <code class="docutils literal notranslate"><span class="pre">Essential</span></code>, then <code class="docutils literal notranslate"><span class="pre">dpkg</span></code> will automatically remove the package which is causing the conflict. Otherwise, it will halt the installation of the new package with an error. This mechanism is specifically designed to produce an error when the installed package is <code class="docutils literal notranslate"><span class="pre">Essential</span></code>, but the new package is not.</p> <p>A package will not cause a conflict merely because its configuration files are still installed; it must be at least “Half-Installed”.</p> <p>A special exception is made for packages which declare a conflict with their own package name, or with a virtual package which they provide (see below): this does not prevent their installation, and allows a package to conflict with others providing a replacement for it. You use this feature when you want the package in question to be the only package providing some feature.</p> <p>Normally, <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> should be used instead of <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code> since <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code> imposes a stronger restriction on the ordering of package installation or upgrade and can make it more difficult for the package manager to find a correct solution to an upgrade or installation problem. <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> should be used</p> <ul class="simple"> <li><p>when moving a file from one package to another (see <a class="reference internal" href="#s-replaces"><span class="std std-ref">Overwriting files and replacing packages - Replaces</span></a>),</p></li> <li><p>when splitting a package (a special case of the previous one), or</p></li> <li><p>when the breaking package exposes a bug in or interacts badly with particular versions of the broken package.</p></li> </ul> <p><code class="docutils literal notranslate"><span class="pre">Conflicts</span></code> should be used</p> <ul class="simple"> <li><p>when two packages provide the same file and will continue to do so,</p></li> <li><p>in conjunction with <code class="docutils literal notranslate"><span class="pre">Provides</span></code> when only one package providing a given virtual facility can be unpacked at a time (see <a class="reference internal" href="#s-virtual"><span class="std std-ref">Virtual packages - Provides</span></a>),</p></li> <li><p>in other cases where one must prevent simultaneous installation of two packages for reasons that are ongoing (not fixed in a later version of one of the packages) or that must prevent both packages from being unpacked at the same time, not just configured.</p></li> </ul> <p>Be aware that adding <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code> is normally not the best solution when two packages provide the same files. Depending on the reason for that conflict, using alternatives or renaming the files is often a better approach. See, for example, <a class="reference internal" href="ch-files.html#s-binaries"><span class="std std-ref">Binaries</span></a>.</p> <p>Neither <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> nor <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code> should be used unless two packages cannot be installed at the same time or installing them both causes one of them to be broken or unusable. Having similar functionality or performing the same tasks as another package is not sufficient reason to declare <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> or <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code> with that package.</p> <p>A <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code> entry may have an “earlier than” version clause if the reason for the conflict is corrected in a later version of one of the packages. However, normally the presence of an “earlier than” version clause is a sign that <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> should have been used instead. An “earlier than” version clause in <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code> prevents <code class="docutils literal notranslate"><span class="pre">dpkg</span></code> from upgrading or installing the package which declares such a conflict until the upgrade or removal of the conflicted-with package has been completed, which is a strong restriction.</p> </section> <section id="virtual-packages-provides"> <span id="s-virtual"></span><h2><span class="section-number">7.5. </span>Virtual packages - <code class="docutils literal notranslate"><span class="pre">Provides</span></code><a class="headerlink" href="#virtual-packages-provides" title="Permalink to this headline">¶</a></h2> <p>As well as the names of actual (“concrete”) packages, the package relationship fields <code class="docutils literal notranslate"><span class="pre">Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Recommends</span></code>, <code class="docutils literal notranslate"><span class="pre">Suggests</span></code>, <code class="docutils literal notranslate"><span class="pre">Enhances</span></code>, <code class="docutils literal notranslate"><span class="pre">Pre-Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Breaks</span></code>, <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends-Indep</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends-Arch</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Conflicts</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Conflicts-Indep</span></code> and <code class="docutils literal notranslate"><span class="pre">Build-Conflicts-Arch</span></code> may mention “virtual packages”.</p> <p>A <em>virtual package</em> is one which appears in the <code class="docutils literal notranslate"><span class="pre">Provides</span></code> control field of another package. The effect is as if the package(s) which provide a particular virtual package name had been listed by name everywhere the virtual package name appears. (See also <a class="reference internal" href="ch-binary.html#s-virtual-pkg"><span class="std std-ref">Virtual packages</span></a>)</p> <p>If there are both concrete and virtual packages of the same name, then the dependency may be satisfied (or the conflict caused) by either the concrete package with the name in question or any other concrete package which provides the virtual package with the name in question. This is so that, for example, supposing we have</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Package</span><span class="p">:</span> <span class="n">foo</span> <span class="n">Depends</span><span class="p">:</span> <span class="n">bar</span> </pre></div> </div> <p>and someone else releases an enhanced version of the <code class="docutils literal notranslate"><span class="pre">bar</span></code> package they can say:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Package</span><span class="p">:</span> <span class="n">bar</span><span class="o">-</span><span class="n">plus</span> <span class="n">Provides</span><span class="p">:</span> <span class="n">bar</span> </pre></div> </div> <p>and the <code class="docutils literal notranslate"><span class="pre">bar-plus</span></code> package will now also satisfy the dependency for the <code class="docutils literal notranslate"><span class="pre">foo</span></code> package.</p> <p>A <code class="docutils literal notranslate"><span class="pre">Provides</span></code> field may contain version numbers, and such a version number will be considered when considering a dependency on or conflict with the virtual package name. For example, given the following packages:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Package</span><span class="p">:</span> <span class="n">foo</span> <span class="n">Depends</span><span class="p">:</span> <span class="n">bar</span> <span class="p">(</span><span class="o">>=</span> <span class="mf">1.0</span><span class="p">)</span> <span class="n">Package</span><span class="p">:</span> <span class="n">bar</span> <span class="n">Version</span><span class="p">:</span> <span class="mf">0.9</span> <span class="n">Package</span><span class="p">:</span> <span class="n">bar</span><span class="o">-</span><span class="n">plus</span> <span class="n">Provides</span><span class="p">:</span> <span class="n">bar</span> <span class="p">(</span><span class="o">=</span> <span class="mf">1.0</span><span class="p">)</span> </pre></div> </div> <p>the <code class="docutils literal notranslate"><span class="pre">bar-plus</span></code> package will satisfy the dependency for the <code class="docutils literal notranslate"><span class="pre">foo</span></code> package with the virtual package name, as above. If the <code class="docutils literal notranslate"><span class="pre">Provides</span></code> field does not specify a version number, it will not satisfy versioned dependencies or violate versioned <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code> or <code class="docutils literal notranslate"><span class="pre">Breaks</span></code>. For example, given the following packages:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Package</span><span class="p">:</span> <span class="n">foo</span> <span class="n">Depends</span><span class="p">:</span> <span class="n">bar</span> <span class="p">(</span><span class="o">>=</span> <span class="mf">1.0</span><span class="p">)</span> <span class="n">Package</span><span class="p">:</span> <span class="n">bar</span> <span class="n">Version</span><span class="p">:</span> <span class="mf">0.9</span> <span class="n">Package</span><span class="p">:</span> <span class="n">bar</span><span class="o">-</span><span class="n">plus</span> <span class="n">Provides</span><span class="p">:</span> <span class="n">bar</span> <span class="p">(</span><span class="o">=</span> <span class="mf">1.0</span><span class="p">)</span> <span class="n">Package</span><span class="p">:</span> <span class="n">bar</span><span class="o">-</span><span class="n">clone</span> <span class="n">Provides</span><span class="p">:</span> <span class="n">bar</span> </pre></div> </div> <p>the <code class="docutils literal notranslate"><span class="pre">bar-plus</span></code> package will satisfy the dependency for the <code class="docutils literal notranslate"><span class="pre">foo</span></code> package, but the <code class="docutils literal notranslate"><span class="pre">bar-clone</span></code> package will not.</p> <p>To specify which of a set of real packages should be the default to satisfy a particular dependency on a virtual package, list the real package as an alternative before the virtual one.</p> <p>If the virtual package represents a facility that can only be provided by one real package at a time, such as the mail-transport-agent virtual package that requires installation of a binary that would conflict with all other providers of that virtual package (see <a class="reference internal" href="ch-customized-programs.html#s-mail-transport-agents"><span class="std std-ref">Mail transport, delivery and user agents</span></a>), all packages providing that virtual package should also declare a conflict with it using <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code>. This will ensure that at most one provider of that virtual package is unpacked or installed at a time.</p> </section> <section id="overwriting-files-and-replacing-packages-replaces"> <span id="s-replaces"></span><h2><span class="section-number">7.6. </span>Overwriting files and replacing packages - <code class="docutils literal notranslate"><span class="pre">Replaces</span></code><a class="headerlink" href="#overwriting-files-and-replacing-packages-replaces" title="Permalink to this headline">¶</a></h2> <p>Packages can declare in their control file that they should overwrite files in certain other packages, or completely replace other packages. The <code class="docutils literal notranslate"><span class="pre">Replaces</span></code> control field has these two distinct purposes.</p> <section id="overwriting-files-in-other-packages"> <span id="s7-6-1"></span><h3><span class="section-number">7.6.1. </span>Overwriting files in other packages<a class="headerlink" href="#overwriting-files-in-other-packages" title="Permalink to this headline">¶</a></h3> <p>It is usually an error for a package to contain files which are on the system in another package. However, if the overwriting package declares that it <code class="docutils literal notranslate"><span class="pre">Replaces</span></code> the one containing the file being overwritten, then <code class="docutils literal notranslate"><span class="pre">dpkg</span></code> will replace the file from the old package with that from the new. The file will no longer be listed as “owned” by the old package and will be taken over by the new package. Normally, <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> should be used in conjunction with <code class="docutils literal notranslate"><span class="pre">Replaces</span></code>. <a class="footnote-reference brackets" href="#id11" id="id4">4</a></p> <p>For example, if a package foo is split into foo and foo-data starting at version 1.2-3, foo-data would have the fields</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Replaces</span><span class="p">:</span> <span class="n">foo</span> <span class="p">(</span><span class="o"><<</span> <span class="mf">1.2</span><span class="o">-</span><span class="mi">3</span><span class="p">)</span> <span class="n">Breaks</span><span class="p">:</span> <span class="n">foo</span> <span class="p">(</span><span class="o"><<</span> <span class="mf">1.2</span><span class="o">-</span><span class="mi">3</span><span class="p">)</span> </pre></div> </div> <p>in its control file. The new version of the package foo would normally have the field</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Depends</span><span class="p">:</span> <span class="n">foo</span><span class="o">-</span><span class="n">data</span> <span class="p">(</span><span class="o">>=</span> <span class="mf">1.2</span><span class="o">-</span><span class="mi">3</span><span class="p">)</span> </pre></div> </div> <p>(or possibly <code class="docutils literal notranslate"><span class="pre">Recommends</span></code> or even <code class="docutils literal notranslate"><span class="pre">Suggests</span></code> if the files moved into foo-data are not required for normal operation).</p> <p>If a package is completely replaced in this way, so that <code class="docutils literal notranslate"><span class="pre">dpkg</span></code> does not know of any files it still contains, it is considered to have “disappeared”. It will be marked as not wanted on the system (selected for removal) and “Not-Installed”. Any <code class="docutils literal notranslate"><span class="pre">conffile</span></code>s details noted for the package will be ignored, as they will have been taken over by the overwriting package. The package’s <code class="docutils literal notranslate"><span class="pre">postrm</span></code> script will be run with a special argument to allow the package to do any final cleanup required. See <a class="reference internal" href="ch-maintainerscripts.html#s-mscriptsinstact"><span class="std std-ref">Summary of ways maintainer scripts are called</span></a>. <a class="footnote-reference brackets" href="#id12" id="id5">5</a></p> <p>For this usage of <code class="docutils literal notranslate"><span class="pre">Replaces</span></code>, virtual packages (see <a class="reference internal" href="#s-virtual"><span class="std std-ref">Virtual packages - Provides</span></a>) are not considered when looking at a <code class="docutils literal notranslate"><span class="pre">Replaces</span></code> field. The packages declared as being replaced must be mentioned by their real names.</p> <p>This usage of <code class="docutils literal notranslate"><span class="pre">Replaces</span></code> only takes effect when both packages are at least partially on the system at once. It is not relevant if the packages conflict unless the conflict has been overridden.</p> </section> <section id="replacing-whole-packages-forcing-their-removal"> <span id="s7-6-2"></span><h3><span class="section-number">7.6.2. </span>Replacing whole packages, forcing their removal<a class="headerlink" href="#replacing-whole-packages-forcing-their-removal" title="Permalink to this headline">¶</a></h3> <p>Second, <code class="docutils literal notranslate"><span class="pre">Replaces</span></code> allows the packaging system to resolve which package should be removed when there is a conflict (see <a class="reference internal" href="#s-conflicts"><span class="std std-ref">Conflicting binary packages - Conflicts</span></a>). This usage only takes effect when the two packages <em>do</em> conflict, so that the two usages of this field do not interfere with each other.</p> <p>In this situation, the package declared as being replaced can be a virtual package, so for example, all mail transport agents (MTAs) would have the following fields in their control files:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Provides</span><span class="p">:</span> <span class="n">mail</span><span class="o">-</span><span class="n">transport</span><span class="o">-</span><span class="n">agent</span> <span class="n">Conflicts</span><span class="p">:</span> <span class="n">mail</span><span class="o">-</span><span class="n">transport</span><span class="o">-</span><span class="n">agent</span> <span class="n">Replaces</span><span class="p">:</span> <span class="n">mail</span><span class="o">-</span><span class="n">transport</span><span class="o">-</span><span class="n">agent</span> </pre></div> </div> <p>ensuring that only one MTA can be unpacked at any one time. See <a class="reference internal" href="#s-virtual"><span class="std std-ref">Virtual packages - Provides</span></a> for more information about this example.</p> </section> </section> <section id="relationships-between-source-and-binary-packages-build-depends-build-depends-indep-build-depends-arch-build-conflicts-build-conflicts-indep-build-conflicts-arch"> <span id="s-sourcebinarydeps"></span><h2><span class="section-number">7.7. </span>Relationships between source and binary packages - <code class="docutils literal notranslate"><span class="pre">Build-Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends-Indep</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends-Arch</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Conflicts</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Conflicts-Indep</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Conflicts-Arch</span></code><a class="headerlink" href="#relationships-between-source-and-binary-packages-build-depends-build-depends-indep-build-depends-arch-build-conflicts-build-conflicts-indep-build-conflicts-arch" title="Permalink to this headline">¶</a></h2> <p>Source packages that require certain binary packages to be installed or absent at the time of building the package may declare relationships to those binary packages.</p> <p>This is done using the <code class="docutils literal notranslate"><span class="pre">Build-Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends-Indep</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends-Arch</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Conflicts</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Conflicts-Indep</span></code> and <code class="docutils literal notranslate"><span class="pre">Build-Conflicts-Arch</span></code> control fields.</p> <p>Build-dependencies on “build-essential” binary packages can be omitted. Please see <a class="reference internal" href="ch-source.html#s-pkg-relations"><span class="std std-ref">Package relationships</span></a> for more information.</p> <p>The dependencies and conflicts they define must be satisfied (as defined earlier for binary packages) in order to invoke the targets in <code class="docutils literal notranslate"><span class="pre">debian/rules</span></code>, as follows:</p> <dl class="simple"> <dt><code class="docutils literal notranslate"><span class="pre">clean</span></code></dt><dd><p>Only the <code class="docutils literal notranslate"><span class="pre">Build-Depends</span></code> and <code class="docutils literal notranslate"><span class="pre">Build-Conflicts</span></code> fields must be satisfied when this target is invoked.</p> </dd> <dt><code class="docutils literal notranslate"><span class="pre">build-arch</span></code>, and <code class="docutils literal notranslate"><span class="pre">binary-arch</span></code></dt><dd><p>The <code class="docutils literal notranslate"><span class="pre">Build-Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Conflicts</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends-Arch</span></code>, and <code class="docutils literal notranslate"><span class="pre">Build-Conflicts-Arch</span></code> fields must be satisfied when these targets are invoked.</p> </dd> <dt><code class="docutils literal notranslate"><span class="pre">build-indep</span></code>, and <code class="docutils literal notranslate"><span class="pre">binary-indep</span></code></dt><dd><p>The <code class="docutils literal notranslate"><span class="pre">Build-Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Conflicts</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends-Indep</span></code>, and <code class="docutils literal notranslate"><span class="pre">Build-Conflicts-Indep</span></code> fields must be satisfied when these targets are invoked.</p> </dd> <dt><code class="docutils literal notranslate"><span class="pre">build</span></code> and <code class="docutils literal notranslate"><span class="pre">binary</span></code></dt><dd><p>The <code class="docutils literal notranslate"><span class="pre">Build-Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Conflicts</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends-Indep</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Conflicts-Indep</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends-Arch</span></code>, and <code class="docutils literal notranslate"><span class="pre">Build-Conflicts-Arch</span></code> fields must be satisfied when these targets are invoked.</p> </dd> </dl> </section> <section id="additional-source-packages-used-to-build-the-binary-built-using"> <span id="s-built-using"></span><h2><span class="section-number">7.8. </span>Additional source packages used to build the binary - <code class="docutils literal notranslate"><span class="pre">Built-Using</span></code><a class="headerlink" href="#additional-source-packages-used-to-build-the-binary-built-using" title="Permalink to this headline">¶</a></h2> <p>Some binary packages incorporate parts of other packages when built but do not have to depend on those packages. Examples include linking with static libraries or incorporating source code from another package during the build. In this case, the source packages of those other packages are part of the complete source (the binary package is not reproducible without them).</p> <p>When the license of either the incorporated parts or the incorporating binary package requires that the full source code of the incorporating binary package be made available, the <code class="docutils literal notranslate"><span class="pre">Built-Using</span></code> field must list the corresponding source package for any affected binary package incorporated during the build, <a class="footnote-reference brackets" href="#id13" id="id6">6</a> including an “exactly equal” (“=”) version relation on the version that was used to build that version of the incorporating binary package. <a class="footnote-reference brackets" href="#id14" id="id7">7</a></p> <p>This causes the Debian archive to retain the versions of the source packages that were actually incorporated. In particular, if the versions of the incorporated parts are updated but the incorporating binary package is not rebuilt, the older versions of the incorporated parts will remain in the archive in order to satisfy the license.</p> <p>A package using the source code from the gcc-4.6-source binary package built from the gcc-4.6 source package would have this field in its control file:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Built</span><span class="o">-</span><span class="n">Using</span><span class="p">:</span> <span class="n">gcc</span><span class="o">-</span><span class="mf">4.6</span> <span class="p">(</span><span class="o">=</span> <span class="mf">4.6</span><span class="o">.</span><span class="mi">0</span><span class="o">-</span><span class="mi">11</span><span class="p">)</span> </pre></div> </div> <p>A package including binaries from grub2 and loadlin would have this field in its control file:</p> <div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Built</span><span class="o">-</span><span class="n">Using</span><span class="p">:</span> <span class="n">grub2</span> <span class="p">(</span><span class="o">=</span> <span class="mf">1.99</span><span class="o">-</span><span class="mi">9</span><span class="p">),</span> <span class="n">loadlin</span> <span class="p">(</span><span class="o">=</span> <span class="mf">1.6e-1</span><span class="p">)</span> </pre></div> </div> <p>This field should be used only when there are license or DFSG requirements to retain the referenced source packages. It should not be added solely as a way to locate packages that need to be rebuilt against newer versions of their build dependencies.</p> <dl class="footnote brackets"> <dt class="label" id="id8"><span class="brackets"><a class="fn-backref" href="#id1">1</a></span></dt> <dd><p>While <code class="docutils literal notranslate"><span class="pre">Build-Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends-Indep</span></code> and <code class="docutils literal notranslate"><span class="pre">Build-Depends-Arch</span></code> permit the use of alternative dependencies, these are not normally used by the Debian autobuilders. To avoid inconsistency between repeated builds of a package, the autobuilders will default to selecting the first alternative, after reducing any architecture-specific restrictions for the build architecture in question. While this may limit the usefulness of alternatives in a single release, they can still be used to provide flexibility in building the same package across multiple distributions or releases, where a particular dependency is met by differently named packages.</p> </dd> <dt class="label" id="id9"><span class="brackets"><a class="fn-backref" href="#id2">2</a></span></dt> <dd><p>The relations <code class="docutils literal notranslate"><span class="pre"><</span></code> and <code class="docutils literal notranslate"><span class="pre">></span></code> were previously allowed, but they were confusingly defined to mean earlier/later or equal rather than strictly earlier/later. <code class="docutils literal notranslate"><span class="pre">dpkg</span></code> still supports them with a warning, but they are no longer allowed by Debian Policy.</p> </dd> <dt class="label" id="id10"><span class="brackets"><a class="fn-backref" href="#id3">3</a></span></dt> <dd><p>This approach makes dependency resolution easier. If two packages A and B are being upgraded, the installed package A depends on exactly the installed package B, and the new package A depends on exactly the new package B (a common situation when upgrading shared libraries and their corresponding development packages), satisfying the dependencies at every stage of the upgrade would be impossible. This relaxed restriction means that both new packages can be unpacked together and then configured in their dependency order.</p> </dd> <dt class="label" id="id11"><span class="brackets"><a class="fn-backref" href="#id4">4</a></span></dt> <dd><p>To see why <code class="docutils literal notranslate"><span class="pre">Breaks</span></code> is normally needed in addition to <code class="docutils literal notranslate"><span class="pre">Replaces</span></code>, consider the case of a file in the package foo being taken over by the package foo-data. <code class="docutils literal notranslate"><span class="pre">Replaces</span></code> will allow foo-data to be installed and take over that file. However, without <code class="docutils literal notranslate"><span class="pre">Breaks</span></code>, nothing requires foo to be upgraded to a newer version that knows it does not include that file and instead depends on foo-data. Nothing would prevent the new foo-data package from being installed and then removed, removing the file that it took over from foo. After that operation, the package manager would think the system was in a consistent state, but the foo package would be missing one of its files.</p> </dd> <dt class="label" id="id12"><span class="brackets"><a class="fn-backref" href="#id5">5</a></span></dt> <dd><p>Replaces is a one way relationship. You have to install the replacing package after the replaced package.</p> </dd> <dt class="label" id="id13"><span class="brackets"><a class="fn-backref" href="#id6">6</a></span></dt> <dd><p><code class="docutils literal notranslate"><span class="pre">Build-Depends</span></code> in the source package is not adequate since it (rightfully) does not document the exact version used in the build.</p> </dd> <dt class="label" id="id14"><span class="brackets"><a class="fn-backref" href="#id7">7</a></span></dt> <dd><p>The archive software might reject packages that refer to non-existent sources.</p> </dd> </dl> </section> </section> <div class="clearer"></div> </div> </div> </div> <div class="sphinxsidebar" role="navigation" aria-label="main navigation"> <div class="sphinxsidebarwrapper"> <h3><a href="index.html">Table of Contents</a></h3> <ul> <li><a class="reference internal" href="#">7. Declaring relationships between packages</a><ul> <li><a class="reference internal" href="#syntax-of-relationship-fields">7.1. Syntax of relationship fields</a></li> <li><a class="reference internal" href="#binary-dependencies-depends-recommends-suggests-enhances-pre-depends">7.2. Binary Dependencies - <code class="docutils literal notranslate"><span class="pre">Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Recommends</span></code>, <code class="docutils literal notranslate"><span class="pre">Suggests</span></code>, <code class="docutils literal notranslate"><span class="pre">Enhances</span></code>, <code class="docutils literal notranslate"><span class="pre">Pre-Depends</span></code></a></li> <li><a class="reference internal" href="#packages-which-break-other-packages-breaks">7.3. Packages which break other packages - <code class="docutils literal notranslate"><span class="pre">Breaks</span></code></a></li> <li><a class="reference internal" href="#conflicting-binary-packages-conflicts">7.4. Conflicting binary packages - <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code></a></li> <li><a class="reference internal" href="#virtual-packages-provides">7.5. Virtual packages - <code class="docutils literal notranslate"><span class="pre">Provides</span></code></a></li> <li><a class="reference internal" href="#overwriting-files-and-replacing-packages-replaces">7.6. Overwriting files and replacing packages - <code class="docutils literal notranslate"><span class="pre">Replaces</span></code></a><ul> <li><a class="reference internal" href="#overwriting-files-in-other-packages">7.6.1. Overwriting files in other packages</a></li> <li><a class="reference internal" href="#replacing-whole-packages-forcing-their-removal">7.6.2. Replacing whole packages, forcing their removal</a></li> </ul> </li> <li><a class="reference internal" href="#relationships-between-source-and-binary-packages-build-depends-build-depends-indep-build-depends-arch-build-conflicts-build-conflicts-indep-build-conflicts-arch">7.7. Relationships between source and binary packages - <code class="docutils literal notranslate"><span class="pre">Build-Depends</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends-Indep</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Depends-Arch</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Conflicts</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Conflicts-Indep</span></code>, <code class="docutils literal notranslate"><span class="pre">Build-Conflicts-Arch</span></code></a></li> <li><a class="reference internal" href="#additional-source-packages-used-to-build-the-binary-built-using">7.8. Additional source packages used to build the binary - <code class="docutils literal notranslate"><span class="pre">Built-Using</span></code></a></li> </ul> </li> </ul> <h4>Previous topic</h4> <p class="topless"><a href="ch-maintainerscripts.html" title="previous chapter"><span class="section-number">6. </span>Package maintainer scripts and installation procedure</a></p> <h4>Next topic</h4> <p class="topless"><a href="ch-sharedlibs.html" title="next chapter"><span class="section-number">8. </span>Shared libraries</a></p> <div role="note" aria-label="source link"> <h3>This Page</h3> <ul class="this-page-menu"> <li><a href="_sources/ch-relationships.rst.txt" rel="nofollow">Show Source</a></li> </ul> </div> <div id="searchbox" style="display: none" role="search"> <h3 id="searchlabel">Quick search</h3> <div class="searchformwrapper"> <form class="search" action="search.html" method="get"> <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/> <input type="submit" value="Go" /> </form> </div> </div> <script>$('#searchbox').show(0);</script> </div> </div> <div class="clearer"></div> </div> <div class="related" role="navigation" aria-label="related navigation"> <h3>Navigation</h3> <ul> <li class="right" style="margin-right: 10px"> <a href="genindex.html" title="General Index" >index</a></li> <li class="right" > <a href="ch-sharedlibs.html" title="8. Shared libraries" >next</a> |</li> <li class="right" > <a href="ch-maintainerscripts.html" title="6. Package maintainer scripts and installation procedure" >previous</a> |</li> <li class="nav-item nav-item-0"><a href="index.html">Debian Policy Manual v4.6.0.1</a> »</li> <li class="nav-item nav-item-this"><a href=""><span class="section-number">7. </span>Declaring relationships between packages</a></li> </ul> </div> <div class="footer" role="contentinfo"> Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 4.2.0. </div> </body> </html>