path: root/locales/ja/LC_MESSAGES/ch-relationships.po

# SOME DESCRIPTIVE TITLE.
# Copyright (C) 1996, 1997, 1998 Ian Jackson, Christian Schwarz, 1998-2017,
# The Debian Policy Mailing List
# This file is distributed under the same license as the Debian Policy
# Manual package.
# FIRST AUTHOR <EMAIL@ADDRESS>, 2018.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Debian Policy Manual 4.1.6.0\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2019-11-29 18:08-0700\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Generated-By: Babel 2.6.0\n"

#: ../../ch-relationships.rst:2
msgid "Declaring relationships between packages"
msgstr ""

#: ../../ch-relationships.rst:7
msgid "Syntax of relationship fields"
msgstr ""

#: ../../ch-relationships.rst:9
msgid ""
"These fields all have a uniform syntax. They are a list of package names "
"separated by commas."
msgstr ""

#: ../../ch-relationships.rst:12
msgid ""
"In the ``Depends``, ``Recommends``, ``Suggests``, ``Pre-Depends``, "
"``Build-Depends``, ``Build-Depends-Indep`` and ``Build-Depends-Arch`` "
"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 ``|``. In such a "
"case, that part of the dependency can be satisfied by any one of the "
"alternative packages.  [#]_"
msgstr ""

#: ../../ch-relationships.rst:20
msgid ""
"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 "
":ref:`s-f-Version`."
msgstr ""

#: ../../ch-relationships.rst:26
msgid ""
"The relations allowed are ``<<``, ``<=``, ``=``, ``>=`` and ``>>`` for "
"strictly earlier, earlier or equal, exactly equal, later or equal and "
"strictly later, respectively. The exception is the Provides field, for "
"which only ``=`` is allowed.  [#]_"
msgstr ""

#: ../../ch-relationships.rst:31
msgid ""
"Whitespace may appear at any point in the version specification subject "
"to the rules in :ref:`s-controlsyntax`, 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 ``dpkg`` 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."
msgstr ""

#: ../../ch-relationships.rst:43
msgid "For example, a list of dependencies might appear as:"
msgstr ""

#: ../../ch-relationships.rst:51
msgid ""
"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 :ref:`s-arch-spec`, "
"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.)"
msgstr ""

#: ../../ch-relationships.rst:59
msgid ""
"For build relationship fields (``Build-Depends``, ``Build-Depends-"
"Indep``, ``Build-Depends-Arch``, ``Build-Conflicts``, ``Build-Conflicts-"
"Indep`` and ``Build-Conflicts-Arch``), 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."
msgstr ""

#: ../../ch-relationships.rst:68 ../../ch-relationships.rst:97
msgid "For example:"
msgstr ""

#: ../../ch-relationships.rst:77
msgid ""
"requires ``kernel-headers-2.2.10`` on all architectures other than "
"hurd-i386 and requires ``hurd-dev`` and ``gnumach-dev`` only on "
"hurd-i386. Here is another example showing multiple architectures "
"separated by spaces:"
msgstr ""

#: ../../ch-relationships.rst:88
msgid ""
"For binary relationship fields and the ``Built-Using`` field, the "
"architecture restriction syntax is only supported in the source package "
"control file ``debian/control``. 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 (``Architecture: all``)."
msgstr ""

#: ../../ch-relationships.rst:103
msgid ""
"becomes ``Depends: foo`` when the package is built on the ``i386`` "
"architecture, ``Depends: bar`` when the package is built on the ``amd64``"
" architecture, and omitted entirely in binary packages built on all other"
" architectures."
msgstr ""

#: ../../ch-relationships.rst:108
msgid ""
"If the architecture-restricted dependency is part of a set of "
"alternatives using ``|``, that alternative is ignored completely on "
"architectures that do not match the restriction. For example:"
msgstr ""

#: ../../ch-relationships.rst:116
msgid ""
"is equivalent to ``bar`` on the ``i386`` architecture, to ``foo`` on the "
"``amd64`` architecture, and to ``foo | bar`` on all other architectures."
msgstr ""

#: ../../ch-relationships.rst:120
msgid ""
"Relationships may also be restricted to a certain set of architectures "
"using architecture wildcards in the format described in :ref:`s-arch-"
"wildcard-spec`. The syntax for declaring such restrictions is the same as"
" declaring restrictions using a certain set of architectures without "
"architecture wildcards. For example:"
msgstr ""

#: ../../ch-relationships.rst:130
msgid ""
"is equivalent to ``foo`` on architectures using the Linux kernel and any "
"cpu, ``bar`` on architectures using any kernel and an i386 cpu, and "
"``baz`` on any architecture using a kernel other than Linux."
msgstr ""

#: ../../ch-relationships.rst:134
msgid ""
"Note that the binary package relationship fields such as ``Depends`` "
"appear in one of the binary package sections of the control file, whereas"
" the build-time relationships such as ``Build-Depends`` appear in the "
"source package section of the control file (which is the first section)."
msgstr ""

#: ../../ch-relationships.rst:143
msgid ""
"Binary Dependencies - ``Depends``, ``Recommends``, ``Suggests``, "
"``Enhances``, ``Pre-Depends``"
msgstr ""

#: ../../ch-relationships.rst:145
msgid ""
"Packages can declare in their control file that they have certain "
"relationships to other packages - for example, that they may not be "
"installed at the same time as certain other packages, and/or that they "
"depend on the presence of others."
msgstr ""

#: ../../ch-relationships.rst:150
msgid ""
"This is done using the ``Depends``, ``Pre-Depends``, ``Recommends``, "
"``Suggests``, ``Enhances``, ``Breaks`` and ``Conflicts`` control fields. "
"``Breaks`` is described in :ref:`s-breaks`, and ``Conflicts`` is "
"described in :ref:`s-conflicts`. The rest are described below."
msgstr ""

#: ../../ch-relationships.rst:156
msgid ""
"These seven fields are used to declare a dependency relationship by one "
"package on another. Except for ``Enhances`` and ``Breaks``, they appear "
"in the depending (binary) package's control file. (``Enhances`` appears "
"in the recommending package's control file, and ``Breaks`` appears in the"
" version of depended-on package which causes the named package to break)."
msgstr ""

#: ../../ch-relationships.rst:163
msgid ""
"A ``Depends`` field takes effect *only* 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 ``Pre-Depends`` 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, ``Recommends``, ``Suggests`` and ``Enhances``, are only used by "
"the various front-ends to ``dpkg`` such as ``apt-get``, ``aptitude``, and"
" ``dselect``.)"
msgstr ""

#: ../../ch-relationships.rst:177
msgid ""
"Since ``Depends`` 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.  [#]_"
msgstr ""

#: ../../ch-relationships.rst:181
msgid ""
"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 ``postinst`` "
"script, then the cycle will be broken at that package; this ensures that "
"all ``postinst`` 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 ``postinst`` scripts."
msgstr ""

#: ../../ch-relationships.rst:195
msgid "The meaning of the five dependency fields is as follows:"
msgstr ""

#: ../../ch-relationships.rst:224
msgid "``Depends``"
msgstr ""

#: ../../ch-relationships.rst:198
msgid ""
"This declares an absolute dependency. A package will not be configured "
"unless all of the packages listed in its ``Depends`` field have been "
"correctly configured (unless there is a circular dependency as described "
"above)."
msgstr ""

#: ../../ch-relationships.rst:203
msgid ""
"The ``Depends`` field should be used if the depended-on package is "
"required for the depending package to provide a significant amount of "
"functionality."
msgstr ""

#: ../../ch-relationships.rst:207
msgid ""
"The ``Depends`` field should also be used if the ``postinst`` or "
"``prerm`` scripts require the depended-on package to be unpacked or "
"configured in order to run. In the case of ``postinst configure``, 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 "
"``prerm`` or other ``postinst`` 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."
msgstr ""

#: ../../ch-relationships.rst:217
msgid ""
"Finally, the ``Depends`` field should be used if the depended-on package "
"is needed by the ``postrm`` script to fully clean up after the package "
"removal. There is no guarantee that package dependencies will be "
"available when ``postrm`` is run, but the depended-on package is more "
"likely to be available if the package declares a dependency (particularly"
" in the case of ``postrm remove``). The ``postrm`` script must gracefully"
" skip actions that require a dependency if that dependency isn't "
"available."
msgstr ""

#: ../../ch-relationships.rst:230
msgid "``Recommends``"
msgstr ""

#: ../../ch-relationships.rst:227
msgid "This declares a strong, but not absolute, dependency."
msgstr ""

#: ../../ch-relationships.rst:229
msgid ""
"The ``Recommends`` field should list packages that would be found "
"together with this one in all but unusual installations."
msgstr ""

#: ../../ch-relationships.rst:237
msgid "``Suggests``"
msgstr ""

#: ../../ch-relationships.rst:233
msgid ""
"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."
msgstr ""

#: ../../ch-relationships.rst:242
msgid "``Enhances``"
msgstr ""

#: ../../ch-relationships.rst:240
msgid ""
"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."
msgstr ""

#: ../../ch-relationships.rst:281
msgid "``Pre-Depends``"
msgstr ""

#: ../../ch-relationships.rst:245
msgid ""
"This field is like ``Depends``, except that it also forces ``dpkg`` to "
"complete installation of the packages named before even starting the "
"installation of the package which declares the pre-dependency, as "
"follows:"
msgstr ""

#: ../../ch-relationships.rst:250
msgid ""
"When a package declaring a pre-dependency is about to be *unpacked* the "
"pre-dependency can be satisfied if the depended-on package is either "
"fully configured, *or even if* 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 ``Pre-Depends`` field."
msgstr ""

#: ../../ch-relationships.rst:260
msgid ""
"When the package declaring a pre-dependency is about to be *configured*, "
"the pre-dependency will be treated as a normal ``Depends``. It will be "
"considered satisfied only if the depended-on package has been correctly "
"configured. However, unlike with ``Depends``, ``Pre-Depends`` does not "
"permit circular dependencies to be broken. If a circular dependency is "
"encountered while attempting to honor ``Pre-Depends``, the installation "
"will be aborted."
msgstr ""

#: ../../ch-relationships.rst:269
msgid ""
"``Pre-Depends`` are also required if the ``preinst`` script depends on "
"the named package. It is best to avoid this situation if possible."
msgstr ""

#: ../../ch-relationships.rst:273
msgid ""
"``Pre-Depends`` 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."
msgstr ""

#: ../../ch-relationships.rst:278
msgid ""
"You should not specify a ``Pre-Depends`` entry for a package before this "
"has been discussed on the ``debian-devel`` mailing list and a consensus "
"about doing that has been reached. See :ref:`s-dependencies`."
msgstr ""

#: ../../ch-relationships.rst:283
msgid ""
"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 "
"``Depends`` 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."
msgstr ""

#: ../../ch-relationships.rst:295
msgid "Packages which break other packages - ``Breaks``"
msgstr ""

#: ../../ch-relationships.rst:297
msgid ""
"When one binary package declares that it breaks another, ``dpkg`` will "
"refuse to allow the package which declares ``Breaks`` to be unpacked "
"unless the broken package is deconfigured first, and it will refuse to "
"allow the broken package to be reconfigured."
msgstr ""

#: ../../ch-relationships.rst:302
msgid ""
"A package will not be regarded as causing breakage merely because its "
"configuration files are still installed; it must be at least \"Half-"
"Installed\"."
msgstr ""

#: ../../ch-relationships.rst:306
msgid ""
"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."
msgstr ""

#: ../../ch-relationships.rst:310
msgid ""
"Normally a ``Breaks`` entry will have an \"earlier than\" version clause;"
" such a ``Breaks`` 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 ``Breaks``. This use of "
"``Breaks`` will inform higher-level package management tools that the "
"broken package must be upgraded before the new one."
msgstr ""

#: ../../ch-relationships.rst:318
msgid ""
"If the breaking package also overwrites some files from the older "
"package, it should use ``Replaces`` to ensure this goes smoothly. See "
":ref:`s-replaces` for a full discussion of taking over files from other "
"packages, including how to use ``Breaks`` in those cases."
msgstr ""

#: ../../ch-relationships.rst:324
msgid ""
"Many of the cases where ``Breaks`` should be used were previously handled"
" with ``Conflicts`` because ``Breaks`` did not yet exist. Many "
"``Conflicts`` fields should now be ``Breaks``. See :ref:`s-conflicts` for"
" more information about the differences."
msgstr ""

#: ../../ch-relationships.rst:333
msgid "Conflicting binary packages - ``Conflicts``"
msgstr ""

#: ../../ch-relationships.rst:335
msgid ""
"When one binary package declares a conflict with another using a "
"``Conflicts`` field, ``dpkg`` will refuse to allow them to be unpacked on"
" the system at the same time. This is a stronger restriction than "
"``Breaks``, 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."
msgstr ""

#: ../../ch-relationships.rst:342
msgid ""
"If one package is to be unpacked, the other must be removed first. If the"
" package being unpacked is marked as replacing (see :ref:`s-replaces`, "
"but note that ``Breaks`` 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 ``Essential``, then ``dpkg`` 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 "
"``Essential``, but the new package is not."
msgstr ""

#: ../../ch-relationships.rst:353
msgid ""
"A package will not cause a conflict merely because its configuration "
"files are still installed; it must be at least \"Half-Installed\"."
msgstr ""

#: ../../ch-relationships.rst:356
msgid ""
"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."
msgstr ""

#: ../../ch-relationships.rst:363
msgid ""
"Normally, ``Breaks`` should be used instead of ``Conflicts`` since "
"``Conflicts`` 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."
" ``Breaks`` should be used"
msgstr ""

#: ../../ch-relationships.rst:369
msgid "when moving a file from one package to another (see :ref:`s-replaces`),"
msgstr ""

#: ../../ch-relationships.rst:372
msgid "when splitting a package (a special case of the previous one), or"
msgstr ""

#: ../../ch-relationships.rst:374
msgid ""
"when the breaking package exposes a bug in or interacts badly with "
"particular versions of the broken package."
msgstr ""

#: ../../ch-relationships.rst:377
msgid "``Conflicts`` should be used"
msgstr ""

#: ../../ch-relationships.rst:379
msgid "when two packages provide the same file and will continue to do so,"
msgstr ""

#: ../../ch-relationships.rst:381
msgid ""
"in conjunction with ``Provides`` when only one package providing a given "
"virtual facility may be unpacked at a time (see :ref:`s-virtual`),"
msgstr ""

#: ../../ch-relationships.rst:385
msgid ""
"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."
msgstr ""

#: ../../ch-relationships.rst:390
msgid ""
"Be aware that adding ``Conflicts`` 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, :ref:`s-binaries`."
msgstr ""

#: ../../ch-relationships.rst:395
msgid ""
"Neither ``Breaks`` nor ``Conflicts`` 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 ``Breaks`` or ``Conflicts`` with that package."
msgstr ""

#: ../../ch-relationships.rst:401
msgid ""
"A ``Conflicts`` 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 ``Breaks`` should have been used instead. An "
"\"earlier than\" version clause in ``Conflicts`` prevents ``dpkg`` 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."
msgstr ""

#: ../../ch-relationships.rst:413
msgid "Virtual packages - ``Provides``"
msgstr ""

#: ../../ch-relationships.rst:415
msgid ""
"As well as the names of actual (\"concrete\") packages, the package "
"relationship fields ``Depends``, ``Recommends``, ``Suggests``, "
"``Enhances``, ``Pre-Depends``, ``Breaks``, ``Conflicts``, ``Build-"
"Depends``, ``Build-Depends-Indep``, ``Build-Depends-Arch``, ``Build-"
"Conflicts``, ``Build-Conflicts-Indep`` and ``Build-Conflicts-Arch`` may "
"mention \"virtual packages\"."
msgstr ""

#: ../../ch-relationships.rst:422
msgid ""
"A *virtual package* is one which appears in the ``Provides`` 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 :ref:`s-virtual-"
"pkg`)"
msgstr ""

#: ../../ch-relationships.rst:428
msgid ""
"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"
msgstr ""

#: ../../ch-relationships.rst:439
msgid ""
"and someone else releases an enhanced version of the ``bar`` package they"
" can say:"
msgstr ""

#: ../../ch-relationships.rst:447
msgid ""
"and the ``bar-plus`` package will now also satisfy the dependency for the"
" ``foo`` package."
msgstr ""

#: ../../ch-relationships.rst:450
msgid ""
"A ``Provides`` 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:"
msgstr ""

#: ../../ch-relationships.rst:465
msgid ""
"the ``bar-plus`` package will satisfy the dependency for the ``foo`` "
"package with the virtual package name, as above.  If the ``Provides`` "
"field does not specify a version number, it will not satisfy versioned "
"dependencies or violate versioned ``Conflicts`` or ``Breaks``. For "
"example, given the following packages:"
msgstr ""

#: ../../ch-relationships.rst:485
msgid ""
"the ``bar-plus`` package will satisfy the dependency for the ``foo`` "
"package, but the ``bar-clone`` package will not."
msgstr ""

#: ../../ch-relationships.rst:488
msgid ""
"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."
msgstr ""

#: ../../ch-relationships.rst:492
msgid ""
"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 :ref:`s-mail-transport-"
"agents`), all packages providing that virtual package should also declare"
" a conflict with it using ``Conflicts``. This will ensure that at most "
"one provider of that virtual package is unpacked or installed at a time."
msgstr ""

#: ../../ch-relationships.rst:504
msgid "Overwriting files and replacing packages - ``Replaces``"
msgstr ""

#: ../../ch-relationships.rst:506
msgid ""
"Packages can declare in their control file that they should overwrite "
"files in certain other packages, or completely replace other packages. "
"The ``Replaces`` control field has these two distinct purposes."
msgstr ""

#: ../../ch-relationships.rst:513
msgid "Overwriting files in other packages"
msgstr ""

#: ../../ch-relationships.rst:515
msgid ""
"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 ``Replaces`` the one containing the file being overwritten, then "
"``dpkg`` 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, ``Breaks`` should be"
" used in conjunction with ``Replaces``.  [#]_"
msgstr ""

#: ../../ch-relationships.rst:523
msgid ""
"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"
msgstr ""

#: ../../ch-relationships.rst:531
msgid ""
"in its control file. The new version of the package foo would normally "
"have the field"
msgstr ""

#: ../../ch-relationships.rst:538
msgid ""
"(or possibly ``Recommends`` or even ``Suggests`` if the files moved into "
"foo-data are not required for normal operation)."
msgstr ""

#: ../../ch-relationships.rst:541
msgid ""
"If a package is completely replaced in this way, so that ``dpkg`` 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 ``conffile``\\ s details noted "
"for the package will be ignored, as they will have been taken over by the"
" overwriting package. The package's ``postrm`` script will be run with a "
"special argument to allow the package to do any final cleanup required. "
"See :ref:`s-mscriptsinstact`.  [#]_"
msgstr ""

#: ../../ch-relationships.rst:550
msgid ""
"For this usage of ``Replaces``, virtual packages (see :ref:`s-virtual`) "
"are not considered when looking at a ``Replaces`` field. The packages "
"declared as being replaced must be mentioned by their real names."
msgstr ""

#: ../../ch-relationships.rst:555
msgid ""
"This usage of ``Replaces`` 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."
msgstr ""

#: ../../ch-relationships.rst:562
msgid "Replacing whole packages, forcing their removal"
msgstr ""

#: ../../ch-relationships.rst:564
msgid ""
"Second, ``Replaces`` allows the packaging system to resolve which package"
" should be removed when there is a conflict (see :ref:`s-conflicts`). "
"This usage only takes effect when the two packages *do* conflict, so that"
" the two usages of this field do not interfere with each other."
msgstr ""

#: ../../ch-relationships.rst:570
msgid ""
"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:"
msgstr ""

#: ../../ch-relationships.rst:580
msgid ""
"ensuring that only one MTA can be unpacked at any one time. See "
":ref:`s-virtual` for more information about this example."
msgstr ""

#: ../../ch-relationships.rst:586
msgid ""
"Relationships between source and binary packages - ``Build-Depends``, "
"``Build-Depends-Indep``, ``Build-Depends-Arch``, ``Build-Conflicts``, "
"``Build-Conflicts-Indep``, ``Build-Conflicts-Arch``"
msgstr ""

#: ../../ch-relationships.rst:588
msgid ""
"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."
msgstr ""

#: ../../ch-relationships.rst:592
msgid ""
"This is done using the ``Build-Depends``, ``Build-Depends-Indep``, "
"``Build-Depends-Arch``, ``Build-Conflicts``, ``Build-Conflicts-Indep`` "
"and ``Build-Conflicts-Arch`` control fields."
msgstr ""

#: ../../ch-relationships.rst:596
msgid ""
"Build-dependencies on \"build-essential\" binary packages can be omitted."
" Please see :ref:`s-pkg-relations` for more information."
msgstr ""

#: ../../ch-relationships.rst:599
msgid ""
"The dependencies and conflicts they define must be satisfied (as defined "
"earlier for binary packages) in order to invoke the targets in "
"``debian/rules``, as follows:"
msgstr ""

#: ../../ch-relationships.rst:605
msgid "``clean``"
msgstr ""

#: ../../ch-relationships.rst:604
msgid ""
"Only the ``Build-Depends`` and ``Build-Conflicts`` fields must be "
"satisfied when this target is invoked."
msgstr ""

#: ../../ch-relationships.rst:610
msgid "``build-arch``, and ``binary-arch``"
msgstr ""

#: ../../ch-relationships.rst:608
msgid ""
"The ``Build-Depends``, ``Build-Conflicts``, ``Build-Depends-Arch``, and "
"``Build-Conflicts-Arch`` fields must be satisfied when these targets are "
"invoked."
msgstr ""

#: ../../ch-relationships.rst:615
msgid "``build-indep``, and ``binary-indep``"
msgstr ""

#: ../../ch-relationships.rst:613
msgid ""
"The ``Build-Depends``, ``Build-Conflicts``, ``Build-Depends-Indep``, and "
"``Build-Conflicts-Indep`` fields must be satisfied when these targets are"
" invoked."
msgstr ""

#: ../../ch-relationships.rst:621
msgid "``build`` and ``binary``"
msgstr ""

#: ../../ch-relationships.rst:618
msgid ""
"The ``Build-Depends``, ``Build-Conflicts``, ``Build-Depends-Indep``, "
"``Build-Conflicts-Indep``, ``Build-Depends-Arch``, and ``Build-Conflicts-"
"Arch`` fields must be satisfied when these targets are invoked."
msgstr ""

#: ../../ch-relationships.rst:626
msgid "Additional source packages used to build the binary - ``Built-Using``"
msgstr ""

#: ../../ch-relationships.rst:628
msgid ""
"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)."
msgstr ""

#: ../../ch-relationships.rst:635
msgid ""
"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 ``Built-Using`` field must list the"
" corresponding source package for any affected binary package "
"incorporated during the build, [#]_ including an \"exactly equal\" "
"(\"=\") version relation on the version that was used to build that "
"version of the incorporating binary package.  [#]_"
msgstr ""

#: ../../ch-relationships.rst:643
msgid ""
"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."
msgstr ""

#: ../../ch-relationships.rst:649
msgid ""
"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:"
msgstr ""

#: ../../ch-relationships.rst:657
msgid ""
"A package including binaries from grub2 and loadlin would have this field"
" in its control file:"
msgstr ""

#: ../../ch-relationships.rst:664
msgid ""
"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."
msgstr ""

#: ../../ch-relationships.rst:670
msgid ""
"While ``Build-Depends``, ``Build-Depends-Indep`` and ``Build-Depends-"
"Arch`` 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."
msgstr ""

#: ../../ch-relationships.rst:683
msgid ""
"The relations ``<`` and ``>`` were previously allowed, but they were "
"confusingly defined to mean earlier/later or equal rather than strictly "
"earlier/later. ``dpkg`` still supports them with a warning, but they are "
"no longer allowed by Debian Policy."
msgstr ""

#: ../../ch-relationships.rst:689
msgid ""
"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."
msgstr ""

#: ../../ch-relationships.rst:699
msgid ""
"To see why ``Breaks`` is normally needed in addition to ``Replaces``, "
"consider the case of a file in the package foo being taken over by the "
"package foo-data. ``Replaces`` will allow foo-data to be installed and "
"take over that file. However, without ``Breaks``, 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."
msgstr ""

#: ../../ch-relationships.rst:712
msgid ""
"Replaces is a one way relationship. You have to install the replacing "
"package after the replaced package."
msgstr ""

#: ../../ch-relationships.rst:716
msgid ""
"``Build-Depends`` in the source package is not adequate since it "
"(rightfully) does not document the exact version used in the build."
msgstr ""

#: ../../ch-relationships.rst:720
msgid ""
"The archive software might reject packages that refer to non-existent "
"sources."
msgstr ""

#~ msgid ""
#~ "Source packages that require certain "
#~ "binary packages to be installed or "
#~ "absent at the time of building the"
#~ " package can declare relationships to "
#~ "those binary packages."
#~ msgstr ""

#~ msgid ""
#~ "All of the fields except for "
#~ "``Provides`` 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 :ref:`s-f-Version`."
#~ msgstr ""

#~ msgid ""
#~ "The relations allowed are ``<<``, "
#~ "``<=``, ``=``, ``>=`` and ``>>`` for "
#~ "strictly earlier, earlier or equal, "
#~ "exactly equal, later or equal and "
#~ "strictly later, respectively.  [#]_"
#~ msgstr ""

#~ msgid ""
#~ "If a relationship field has a "
#~ "version number attached, only real "
#~ "packages will be considered to see "
#~ "whether the relationship is satisfied "
#~ "(or the prohibition violated, for a "
#~ "conflict or breakage). In other words,"
#~ " if a version number is specified,"
#~ " this is a request to ignore "
#~ "all ``Provides`` for that package name"
#~ " and consider only real packages. The"
#~ " package manager will assume that a"
#~ " package providing that virtual package "
#~ "is not of the \"right\" version. A"
#~ " ``Provides`` field may not contain "
#~ "version numbers, and the version number"
#~ " of the concrete package which "
#~ "provides a particular virtual package "
#~ "will not be considered when considering"
#~ " a dependency on or conflict with "
#~ "the virtual package name. [#]_"
#~ msgstr ""

#~ msgid ""
#~ "It is possible that a future "
#~ "release of ``dpkg`` may add the "
#~ "ability to specify a version number "
#~ "for each virtual package it provides."
#~ " This feature is not yet present, "
#~ "however, and is expected to be "
#~ "used only infrequently."
#~ msgstr ""

#~ msgid ""
#~ "This field should not be added "
#~ "solely for purposes other than "
#~ "satisfying license or DFSG requirements "
#~ "to provide full source code. In "
#~ "particular, it should not be added "
#~ "solely to enable finding packages that"
#~ " should be rebuilt against newer "
#~ "versions of their build dependencies."
#~ msgstr ""