Debian Policy Manual 4.6.2.0 - en to zh translation catalogue (88 entries)

en: Binary packages
zh: 二进制包

en: The Debian distribution is based on the Debian package management system, called ``dpkg``. Thus, all packages in the Debian distribution must be provided in the ``.deb`` file format.
zh: Debian发行版建立在Debian包管理系统之上，该系统被称为 ``dpkg`` 。因此，Debian发行版中的所有软件包都必须以 ``.deb`` 文件格式提供。

en: A ``.deb`` package contains two sets of files: a set of files to install on the system when the package is installed, and a set of files that provide additional metadata about the package or which are executed when the package is installed or removed. This second set of files is called *package metadata files*. Among those files are the package maintainer scripts and ``control``, the :ref:`binary package control file <s-binarycontrolfiles>` that contains the control fields for the package. Other package metadata files include :ref:`symbols <s-sharedlibs-symbols>` or :ref:`shlibs <s-sharedlibs-shlibdeps>` used to store shared library dependency information and the ``conffiles`` file that lists the package's configuration files (described in :ref:`s-config-files`).
zh: 一个 ``.deb`` 包中包含了两组文件：一组文件会在包被安装时一同被安装在系统上，另一组文件要么提供了相关包的一些附加元数据，或是在包被安装或删除时一同被执行。第二组文件被称为 *包的元数据文件* 。这些文件中有包维护者脚本和 ``control`` ，即 :ref:`binary package control file <s-binarycontrolfiles>` ，它包含了包的控制字段。其他的元数据文件包括用于存储共享库依赖信息的 :ref:`symbols <s-sharedlibs-symbols>` 或 :ref:`shlibs <s-sharedlibs-shlibdeps>` ，以及列出包的配置文件的 ``conffiles`` 文件（在 :ref:`s-config-files` 中有所描述）。

en: There is unfortunately a collision of terminology here between control information files and files in the Debian control file format. Throughout this document, a *control file* refers to a file in the Debian control file format. These files are documented in :doc:`Control files and their fields <ch-controlfields>`. Only files referred to specifically as *package metadata files* are the files included in the package metadata member (called ``control.tar``) of the ``.deb`` file format used by binary packages. Most package metadata files are not in the Debian control file format.
zh: 不幸的是，控制信息文件和Debian控制文件格式的文件之间存在术语冲突。在本文档中， *控制文件* 指的是Debian控制文件格式的文件。这些文件记录在 :doc:`控制文件及其字段 <ch-controlfields>` 中。只有专门被称为是 *包元数据文件* 的文件才是二进制包所用的 ``.deb`` 文件格式的包元数据文件成员（被称作 ``control.tar`` ）中所包含的文件。大多数包元数据文件不具有Debian控制文件格式。

en: The package name
zh: 软件包名

en: Every package must have a name that's unique within the Debian archive.
zh: 每个软件包都必须有一个Debian存档中独一无二的名称。

en: The package name is included in the control field ``Package``, the format of which is described in :ref:`s-f-Package`. The package name is also included as a part of the file name of the ``.deb`` file.
zh: 包名包含在控制字段 ``Package`` 中，其格式在 :ref:`s-f-Package` 中有描述。包名称也包含在 ``.deb`` 文件的文件名中。

en: Packages with potentially offensive content
zh: 含潜在冒犯性内容的软件包

en: As a maintainer you should make a judgement about whether the contents of a package is appropriate to include, whether it needs any kind of content warning, and whether some parts should be split out into a separate package (so that users who want to avoid certain parts can do so).  In making these decisions you should take into account the project's views as expressed in our Diversity Statement.
zh: 作为维护者，你应当判断一个包是否适于被接纳，是否需要某种类型的内容警告，以及该包的某些部分是否应被拆分成单独的包（方便那些想要避免接触该包中某些内容的用户）。在做出这些决定时，你应该考虑我们的多元化声明中表达出的Debian项目的种种观点。

en: If you split out (potentially) offensive or disturbing material into a separate package, you should usually mark this in the package name by adding ``-offensive``.  For example, ``cowsay`` vs ``cowsay-offensive``.  In this situation the ``-offensive`` package can be Suggested by the core package(s), but should not be Recommended or Depended on.
zh: 如果你将（潜在的）冒犯性或干扰性内容拆分到一个单独的包中，那么通常情况下你应该通过在包名称中添加 ``-offensive`` 来对此进行标识。例如， ``cowsay`` 应当被标记为 ``cowsay-offensive`` 。在这种情况下， ``-offensive`` 包可以被核心软件包Suggested，但不应该被它们Recommended或被Depended on。

en: The version of a package
zh: 软件包版本

en: Every package has a version number recorded in its ``Version`` control file field, described in :ref:`s-f-Version`.
zh: 每个包都有一个版本号，它记录在该包控制文件中的 ``Version`` 字段中，如 :ref:`s-f-Version` 中所描述。

en: The package management system imposes an ordering on version numbers, so that it can tell whether packages are being up- or downgraded and so that package system front end applications can tell whether a package it finds available is newer than the one installed on the system. The version number format has the most significant parts (as far as comparison is concerned) at the beginning.
zh: 软件包管理系统对版本号进行排序，以便判断包是否处在升级或降级过程中，从而使得包系统前端应用程序能够判断可用的软件包是否比系统上已安装的包更新。版本号格式最重要的部分（就比较而言）在开头。

en: If an upstream package has problematic version numbers they should be converted to a sane form for use in the ``Version`` field.
zh: 如果上游包的版本号有问题，那么应将它们转换为合理的形式，以便在 ``Version`` 字段中使用。

en: Version numbers based on dates
zh: 基于日期的版本号

en: In general, Debian packages should use the same version numbers as the upstream sources. However, upstream version numbers based on some date formats (sometimes used for development or "snapshot" releases) will not be ordered correctly by the package management software. For example, ``dpkg`` will consider "96May01" to be greater than "96Dec24".
zh: 一般来说，Debian软件包应该使用与上游源代码相同的版本号。然而，软件包管理软件无法对基于某些日期格式（有时用于开发或\“快照\”发布）的上游版本号进行正确排序。例如， ``dpkg``  会将\“96May01\”视作是大于\“96Dec24\”的。

en: To prevent having to use epochs for every new upstream version, the date-based portion of any upstream version number should be given in a way that sorts correctly: four-digit year first, followed by a two-digit numeric month, followed by a two-digit numeric date, possibly with punctuation between the components.
zh: 为避免必须为每个新的上游版本使用epoch，所有上游版本号中基于日期的部分都应该以正确排序的方式给出：首先是四位数年份，然后是两位数的月份，然后是两位数的日期，中间可以通过标点符号连接。

en: Native Debian packages (i.e., packages which have been written especially for Debian) whose version numbers include dates should also follow these rules. If punctuation is desired between the date components, remember that hyphen (``-``) cannot be used in native version numbers. Period (``.``) is normally a good choice.
zh: 版本号包含日期的本土Debian软件包（即专门为Debian编写的软件包）也应遵循这些规则。如果需要用标点符号连接日期，请记住不能在本土版本号中使用连字符 (``-``)。 句点 (``.``) 通常是一个不错的选择。

en: Uniqueness of version numbers
zh: 版本号的唯一性

en: The part of the version number after the epoch must not be reused for a version of the package with different contents once the package has been accepted into the archive, even if the version of the package previously using that part of the version number is no longer present in any archive suites.
zh: 一旦包被纳入存档中，版本号中epoch之后的部分不得再用于该包内容变更后的另一个版本，即使以前使用该版本号相关部分的那一个版本的软件包已经不在存档中出现。

en: This uniqueness requirement applies to the version numbers of source packages and of binary packages, even if the source package producing a given binary package changes.  Thus the version numbers which a binary package must not reuse includes the version numbers of any versions of the binary package ever accepted into the archive, under any source package.
zh: 这种对版本号的唯一性的要求既适用于源码包，也适用于二进制包，即使生成给定二进制包的源码包发生了变化。 因此，二进制包不得重复使用的版本号包括所有源码包给出的、被纳入存档中的二进制包的所有版本号。

en: Additionally, for non-native packages, the upstream version must not be reused for different upstream source code, so that for each source package name and upstream version number there exists exactly one original source archive contents (see :ref:`s-f-Files`).
zh: 此外，对于非本土包，上游版本不得重复用于不同的上游源代码，这意味着每个源码包名称和上游版本号在存档中仅有一个原始源码内容与其相对应（见 :ref:`s-f-Files`）。

en: The reason for these restrictions is as follows.  Epochs are not included in the names of the files that compose source packages, or in the filenames of binary packages, so reusing a version number, even if the epoch differs, results in identically named files with different contents.  This can cause various problems.
zh: 做出这些限制的原因如下。 Epoch不包含在组成源码包的文件名中，也不包含在二进制包的文件名中，因此即使epoch不同，重复使用版本号也会导致存在具有不同内容的同名文件。 这会导致各种问题。

en: If you find yourself wanting to reuse the part of a version number after the epoch, you can just increment the Debian revision, which doesn't need to start at 1 or be consecutive.
zh: 如果你想要重复使用版本号中epoch之后的部分，你可以增加Debian修订号，它不需要从1开始，也不需要是连续数字。

en: The maintainer of a package
zh: 软件包维护者

en: Every package must have a maintainer, except for orphaned packages as described below. The maintainer may be one person or a group of people reachable from a common email address, such as a mailing list. The maintainer is responsible for maintaining the Debian packaging files, evaluating and responding appropriately to reported bugs, uploading new versions of the package (either directly or through a sponsor), ensuring that the package is placed in the appropriate archive area and included in Debian releases as appropriate for the stability and utility of the package, and requesting removal of the package from the Debian distribution if it is no longer useful or maintainable.
zh: 除了后文所述的那种被遗弃的包，每个包都必须有一个维护者。维护者可以是一个人，也可以是一组人，能通过一个共同的电子邮件地址被联系上，例如邮件列表。维护者负责维护Debian打包文件，对软件故障报告进行评估并给出恰当的回应，上传软件包的新版本（要么自行直接上传，要么通过推荐人上传），保证软件包被放进合适的存档分组中，并在维系该包稳定性和实用性的前提下将其纳入Debian发行版，在一个软件包不再有用或无法得到维护的时候，请求将其从Debian发行版中移除。

en: The maintainer must be specified in the ``Maintainer`` control field with their correct name and a working email address. The email address given in the ``Maintainer`` control field must accept mail from those role accounts in Debian used to send automated mails regarding the package. This includes non-spam mail from the bug-tracking system, all mail from the Debian archive maintenance software, and other role accounts or automated processes that are commonly agreed on by the project.  [#]_ If one person or team maintains several packages, they should use the same form of their name and email address in the ``Maintainer`` fields of those packages.
zh: 软件包维护者的信息必须在 ``Maintainer`` 控制字段中得以明确， 这其中必须包含其正确的姓名和正常使用的电子邮件地址。 ``Maintainer`` 控制字段中给出的电子邮件地址必须接收Debian中用于发送与软件包相关的自动邮件的那些角色帐户的邮件。这其中包括来自错误跟踪系统的非垃圾邮件、来自Debian存档维护软件的所有邮件，以及来自那些为Debian项目一致同意的其他角色帐户或自动化流程的邮件。[#]_ 如果一个人或团队维护多个包，他们应当使用在这些包的 ``Maintainer`` 字段中出现的相同形式的姓名和电子邮件地址。

en: The format of the ``Maintainer`` control field is described in :ref:`s-f-Maintainer`.
zh: ``Maintainer`` 控制字段的格式在 :ref:`s-f-Maintainer` 中有描述。

en: If the maintainer of the package is a team of people with a shared email address, the ``Uploaders`` control field must be present and must contain at least one human with their personal email address. See :ref:`s-f-Uploaders` for the syntax of that field.
zh: 如果软件包的维护者是一组拥有共享电子邮件地址的人，那么 ``Uploaders`` 控制字段必须存在并且必须包含至少一个人及其个人电子邮件地址。有关该字段的语法，请参阅 :ref:`s-f-Uploaders` 。

en: An orphaned package is one with no current maintainer. Orphaned packages should have their ``Maintainer`` control field set to ``Debian QA Group <packages@qa.debian.org>``. These packages are considered maintained by the Debian project as a whole until someone else volunteers to take over maintenance.  [#]_
zh: 被遗弃的包指的是那些当前没有维护者的包。遗弃包的 ``Maintainer`` 控制字段应被设置为 ``Debian QA Group <packages@qa.debian.org>`` 。这些软件包被视为由整个Debian项目维护，直到有人志愿接管对其进行维护。 [#]_

en: The description of a package
zh: 软件包描述

en: Every Debian package must have a ``Description`` control field which contains a synopsis and extended description of the package. Technical information about the format of the ``Description`` field is in :ref:`s-f-Description`.
zh: 每个 Debian 软件包都必须有一个 ``Description`` 控制字段，其中包含软件包的概要和扩展性描述。有关 ``Description`` 字段格式的技术信息，见 :ref:`s-f-Description` 。

en: The description should describe the package (the program) to a user (system administrator) who has never met it before so that they have enough information to decide whether they want to install it. This description should not just be copied verbatim from the program's documentation.
zh: 描述应该向以前从未接触过它的用户（系统管理员）描述该包（程序），以便他们有足够的信息来决定是否要安装它。这个描述不应该仅是从该程序文档逐字复制而来。

en: Put important information first, both in the synopsis and extended description. Sometimes only the first part of the synopsis or of the description will be displayed. You can assume that there will usually be a way to see the whole extended description.
zh: 在概要和扩展性描述中，重要的信息放在前面。有时只有概要或描述的第一部分会被显示出来。但是你应该预设整个扩展性描述是可以被看到的。

en: The description should also give information about the significant dependencies and conflicts between this package and others, so that the user knows why these dependencies and conflicts have been declared.
zh: 描述中还应该给出有关此包与其他包之间的重要依赖关系和冲突的信息，以便用户知道为什么会存在对这些依赖关系和冲突的声明。

en: Instructions for configuring or using the package should not be included (that is what installation scripts, manual pages, info files, etc., are for). Copyright statements and other administrivia should not be included either (that is what the copyright file is for).
zh: 描述中不应包括对该包配置或使用的说明（这是安装脚本、手册页、信息文件等要做的）。版权声明和其他管理信息也不应包括在内（这就是版权文件要做的）。

en: The single line synopsis
zh: 单行概要

en: The single line synopsis should be kept brief---certainly under 80 characters.
zh: 单行概要应该保持简短 -- 不能超过80个字符。

en: Do not include the package name in the synopsis line. The display software knows how to display this already, and you do not need to state it. Remember that in many situations the user may only see the synopsis line - make it as informative as you can.
zh: 不要在概要中包含软件包的名称。显示软件知道如何对此进行显示，不需要在描述中再次给出。请记住，在许多情况下，用户可能只会看到概要行 -- 因此，尽可能让它包含所有关键信息。

en: The extended description
zh: 扩展性描述

en: Do not try to continue the single line synopsis into the extended description. This will not work correctly when the full description is displayed, and makes no sense where only the summary (the single line synopsis) is available.
zh: 不要试图将单行概要延续到扩展描述中。这会使得完整描述在被显示的时候不明所以，也会使得只有总结（单行概要）被显示出来的时候不明所以。

en: The extended description should describe what the package does and how it relates to the rest of the system (in terms of, for example, which subsystem it is which part of).
zh: 扩展描述应该描述包的作用以及它与系统其余部分的关系（例如，它属于哪个子系统的哪个部分）。

en: The description field needs to make sense to anyone, even people who have no idea about any of the things the package deals with.  [#]_
zh: 描述字段需要对所有人而言都是一目了然的，即使是对该包所处理的事情一无所知的人也应如此。 [#]_

en: Dependencies
zh: 依赖关系

en: Every package must specify the dependency information about other packages that are required for the first to work correctly.
zh: 每个包都必须指明其正确运作所需的其他包的依赖信息。

en: For example, a dependency entry must be provided for any shared libraries required by a dynamically-linked executable binary in a package.
zh: 例如，必须为包中动态链接的可执行二进制文件所需的所有共享库提供依赖项。

en: Packages are not required to declare any dependencies they have on other packages which are marked ``Essential`` (see below), and should not do so unless they depend on a particular version of that package.  [#]_
zh: 包不需要声明它与那些标记为 ``Essential`` （见下文）的包的依赖关系，除非它们依赖于该包的特定版本，否则不应该做这样的声明。 [#]_

en: Sometimes, unpacking one package requires that another package be first unpacked *and* configured. In this case, the depending package must specify this dependency in the ``Pre-Depends`` control field.
zh: 有时，解压一个包需要先解压 *以及* 配置另一个包。在这种情况下，有依赖的包必须在 ``Pre-Depends`` 控制字段中明确此依赖项。

en: 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.
zh: 在 ``debian-devel`` 邮件列表上进行相关讨论并就讨论结果达成共识之前，不应为软件包指定 ``Pre-Depends`` 条目。

en: The format of the package interrelationship control fields is described in :doc:`Declaring relationships between packages <ch-relationships>`.
zh: 包相互关系控制字段的格式在 :doc:`Declaring relationships between packages <ch-relationships>` 中有所描述。

en: Virtual packages
zh: 虚拟包

en: Sometimes, there are several packages which offer more-or-less the same functionality. In this case, it's useful to define a *virtual package* whose name describes that common functionality. (The virtual packages only exist logically, not physically; that's why they are called *virtual*.) The packages with this particular function will then *provide* the virtual package. Thus, any other package requiring that function can simply depend on the virtual package without having to specify all possible packages individually.
zh: 有的时候，存在几个包提供或多或少相同的功能的情况。在这种情况下，定义一个其名称描述了共同功能的 *虚拟包* 是有帮助的。（虚拟包仅在逻辑上存在，而非物理上存在；这就是它们被称为 *虚拟* 的原因。）具有此特定功能的包将 *提供* 虚拟包。因此，任何其他需要该功能的包都可以直接依赖于虚拟包，而不必单独明确所有可能存在的相关包。

en: All packages should use virtual package names where appropriate, and arrange to create new ones if necessary. They should not use virtual package names (except privately, amongst a cooperating group of packages) unless they have been agreed upon and appear in the list of virtual package names. (See also :ref:`s-virtual`)
zh: 所有包都应在适当的情况下使用虚拟包名称，并在必要时创建新虚拟包名称。除非对虚拟包名称的使用已得到共识并且该名称已经出现在虚拟包名称列表中，否则软件包不应该使用虚拟包名称（在一组合作的包间私下使用除外）。（另见 :ref:`s-virtual`）

en: The latest version of the authoritative list of virtual package names can be found in the ``debian-policy`` package. It is also available from the Debian web mirrors at https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml.
zh: 具有权威性的最新版虚拟包名称列表可以在 ``debian-policy`` 包中找到。也可以从Debian网络镜像获得，网址为 https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml 。

en: The procedure for updating the list is described in the preface to the list.
zh: 列表的前言中描述了对列表进行更显所需的程序。

en: Base system
zh: 基础系统

en: The ``base system`` is a minimum subset of the Debian system that is installed before everything else on a new system. Only very few packages are allowed to form part of the base system, in order to keep the required disk usage very small.
zh: ``base system`` 是 Debian 系统的最小子集，在新系统所有其他部分安装之前被安装。为了保持所需的磁盘使用量非常小，只有很少的包得以构成基础系统的一部分。

en: The base system consists of all those packages with priority ``required`` or ``important``. Many of them will be tagged ``essential`` (see below).
zh: 基础系统由所有优先级为 ``required`` 或 ``important`` 的包组成。其中许多包被标记为 ``essential`` （见下文）。

en: Essential packages
zh: 核心包

en: Essential is defined as the minimal set of functionality that must be available and usable on the system at all times, even when packages are in the "Unpacked" state. Packages are tagged ``essential`` for a system using the ``Essential`` control field. The format of the ``Essential`` control field is described in :ref:`s-f-Essential`.
zh: 核心被定义为在系统中必须存在，且始终可用的最小功能集，即使包处于\“Unpacked\“状态，也是如此。将软件包标记为 ``essential`` 需使用 ``Essential`` 控制字段。 ``Essential`` 控制字段的格式在 :ref:`s-f-Essential` 中有所描述。

en: Since these packages cannot be easily removed (one has to specify an extra *force option* to ``dpkg`` to do so), this flag must not be used unless absolutely necessary. A shared library package must not be tagged ``essential``; dependencies will prevent its premature removal, and we need to be able to remove it when it has been superseded.
zh: 由于这些包不能轻易删除（必须为 ``dpkg`` 指定一个额外的 *强制选项* 才能删除），除非绝对必要，否则不得使用此标志。共享库包不得被标记为 ``essential`` ；依赖关系会防止它被不恰当地删除，而我们需要能够在它被取代时删除它。

en: Since dpkg will not prevent upgrading of other packages while an ``essential`` package is in an unconfigured state, all ``essential`` packages must supply all of their core functionality even when unconfigured after being configured at least once. If the package cannot satisfy this requirement it must not be tagged as essential, and any packages depending on this package must instead have explicit dependency fields as appropriate.
zh: 由于dpkg不会在 ``essential`` 包处于未配置状态时阻止其他包的升级，因此，对于所有 ``essential`` 包来说，即使它们当前处于未配置的状态，但只要这之前至少配置过一次，就必须提供其所有核心功能。如果包不能满足此要求，那么它不得被标记为是核心的，并且依赖于此包的所有包都必须适当地声明依赖字段。

en: Maintainers should take great care in adding any programs, interfaces, or functionality to ``essential`` packages. Packages may assume that functionality provided by ``essential`` packages is always available without declaring explicit dependencies, which means that removing functionality from the Essential set is very difficult and is almost never done. Any capability added to an ``essential`` package therefore creates an obligation to support that capability as part of the Essential set in perpetuity.
zh: 维护人员在向 ``essential`` 包添加任何程序、接口或功能时应格外小心。其他包可能会假定 ``essential`` 包提供的功能始终可用，而无需声明依赖项，这意味着从核心包中删除功能非会变得非常困难，几乎从未有人成功过。因此，添加到 ``essential`` 包的任何功能都会产生一种义务，即永久支持该功能作为核心包的一部分。

en: You must not tag any packages ``essential`` before this has been discussed on the ``debian-devel`` mailing list and a consensus about doing that has been reached.
zh: 在 ``debian-devel`` 邮件列表上对此进行讨论并达成共识之前，不得将任何包标记为 ``essential`` 。

en: Maintainer Scripts
zh: 维护者脚本

en: The package installation scripts should avoid producing output which is unnecessary for the user to see and should rely on ``dpkg`` to stave off boredom on the part of a user installing many packages. This means, amongst other things, not passing the ``--verbose`` option to ``update-alternatives``.
zh: 软件包的安装脚本应该避免产生用户不需要看到的输出，并且应该依靠 ``dpkg`` 来避免让同时安装许多软件包的用户感到无聊。这意味着需要避免的事项之一是给 ``update-alternatives`` 提供 ``--verbose`` 选项。

en: Errors which occur during the execution of an installation script must be checked and the installation must not continue after an error.
zh: 如果安装脚本执行期间发生了错误，必须要对它进行检查，并且在出现错误后不得继续安装。

en: Note that in general :ref:`s-scripts` applies to package maintainer scripts, too.
zh: 需要注意的是，通常情况下 :ref:`s-scripts` 也适用于包维护者脚本。

en: You should not use ``dpkg-divert`` on a file belonging to another package without consulting the maintainer of that package first. When adding or removing diversions, package maintainer scripts must provide the ``--package`` flag to ``dpkg-divert`` and must not use ``--local``.
zh: 在没有先咨询相关包的维护者之前，你不应该在属于另一个包的文件上使用 ``dpkg-divert`` 。在添加或删除转移时，包维护者脚本必须向 ``dpkg-divert`` 提供 ``--package`` 标志并且不得使用 ``--local`` 。

en: All packages which supply an instance of a common command name (or, in general, filename) should generally use ``update-alternatives`` so that they can be installed together. If ``update-alternatives`` is not used, then each package must use ``Conflicts`` to ensure that other packages are removed. (In this case, it may be appropriate to specify a conflict against earlier versions of something that previously did not use ``update-alternatives``; this is an exception to the usual rule that versioned conflicts should be avoided.)
zh: 通常情况下，所有提供通用命令名（或一般情况下，文件名）的包都应使用 ``update-alternatives`` ，以便它们可以一起安装。如果不使用 ``update-alternatives`` ，那么每个包都必须使用 ``Conflicts`` 来确保其他包被删除。（在这种情况下，可以适当指明该包与其未使用 ``update-alternatives`` 的早期版本间的冲突；这是一个例外，因为通常的规则是避免出现一个包在其不同版本间的冲突。）

en: Diversions are primarily intended as a tool for local administrators and local packages to override the behavior of Debian.  While there are some circumstances where one Debian package may need to divert a file installed by another Debian package, such circumstances are rare.  Maintainers should strongly prefer using other overriding mechanisms, instead of diversions, whenever those other mechanisms are sufficient to accomplish the same goal. In other words, diversions in packages should be considered a last resort. Diversion of a file in one Debian package by another Debian package should be coordinated between the maintainers of those packages.
zh: 转移主要是用作让本地管理员和本地软件包能够推翻Debian的行为。虽然存在下面这样一些情况，其中，一个Debian软件包可能需要转移另一个Debian软件包所安装的文件，但是这样的情况非常少见。如果存在一些转移以外的其他推翻机制能够达成同一个目标，那么维护者应强烈偏向使用那些推翻机制。换言之，软件包中的转移应被视为是下下策。由一个Debian包对另一个Debian包的文件转移应由这些包的维护者们协同完成。

en: Alternatives must not be used for ``systemd`` configuration files. The alternatives system does not know how to apply changes to services when updating alternatives, so the resulting behavior would be confusing and unpredictable. Instead, `aliases <https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description>`_ can be used to provide alternative implementations of the same named unit.
zh: 替代系统不得用于 ``systemd`` 配置文件。替代系统不知道如何在更新该系统时应用出现的种种变更， 因此，随后出现的行为会是令人费解或不可预测的。相反， `aliases <https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description>`_ 可以作为替代来实施同名称的unit。

en: Prompting in maintainer scripts
zh: 维护者脚本提示

en: Package maintainer scripts may prompt the user if necessary. Prompting must be done by communicating through a program, such as ``debconf``, which conforms to the Debian Configuration Management Specification, version 2 or higher.
zh: 如有必要，包维护者脚本可以提示用户。提示必须通过一个程序来实现沟通，例如 ``debconf`` ，它遵循Debian配置管理规范的第2版或更高版本。

en: Packages which are essential, or which are dependencies of essential packages, may fall back on another prompting method if no such interface is available when they are executed.
zh: 如果在执行时没有相关的可用接口，核心包或依赖于核心包的包可以依靠其他提示方法。

en: The Debian Configuration Management Specification is included in the ``debconf_specification`` files in the debian-policy package. It is also available from the Debian web mirrors at https://www.debian.org/doc/packaging-manuals/debconf_specification.html.
zh: Debian配置管理规范包含在debian-policy包中的 ``debconf_specification`` 文件中。它也可以从Debian网络镜像中获得，网址为 https://www.debian.org/doc/packaging-manuals/debconf_specification.html 。

en: Packages which use the Debian Configuration Management Specification may contain the additional package metadata files ``config`` and ``templates``. ``config`` is an additional maintainer script used for package configuration, and ``templates`` contains templates used for user prompting. The ``config`` script might be run before the ``preinst`` script and before the package is unpacked or any of its dependencies or pre-dependencies are satisfied. Therefore it must work using only the tools present in *essential* packages.  [#]_
zh: 使用Debian配置管理规范的软件包可能包含额外的控制信息文件 ``config`` 和 ``templates`` 。 `` config`` 是用于配置包的附加维护者脚本， ``templates`` 包含用于用户提示的模板。``config`` 脚本可能会在 ``preinst`` 脚本之前运行，并且在解包或其任何依赖项或前置依赖项得到满足之前运行。因此，它必须能在仅使用 *核心* 包中的工具的情况下正常工作。 [#]_

en: Packages which use the Debian Configuration Management Specification must allow for translation of their user-visible messages by using a gettext-based system such as the one provided by the po-debconf package.
zh: 使用Debian配置管理规范的软件包必须通过使用基于gettext的系统（例如po-debconf软件包提供的系统）来翻译其用户可见的消息。

en: Packages should try to minimize the amount of prompting they need to do, and they should ensure that the user will only ever be asked each question once. This means that packages should try to use appropriate shared configuration files (such as ``/etc/papersize`` and ``/etc/news/server``), and shared debconf variables rather than each prompting for their own list of required pieces of information.
zh: 软件包应该尽量最小化所需提示的数量，并且应该确保每个问题只问用户一次。这意味着包应该尝试使用适当的共享配置文件（例如 ``/etc/papersize`` 和 ``/etc/news/server`` ），以及共享debconf变量，而不是每个包都提示自己所需的信息列表。

en: It also means that an upgrade should not ask the same questions again, unless the user has used ``dpkg --purge`` to remove the package's configuration. The answers to configuration questions should be stored in an appropriate place in ``/etc`` so that the user can modify them, and how this has been done should be documented.
zh: 这也意味着包在升级时不应该再次询问已经问过的问题，除非用户使用 ``dpkg --purge`` 删除了包的配置。配置问题的答案应存储在 ``/etc`` 中适当的地方，以便用户对它们进行修改，并且，这些过程是如何完成的也应当被记录下来。

en: If a package has a vitally important piece of information to pass to the user (such as "don't run me as I am, you must edit the following configuration files first or you risk your system emitting badly-formatted messages"), it should display this in the ``config`` or ``postinst`` script and prompt the user to hit return to acknowledge the message. Copyright messages do not count as vitally important (they belong in ``/usr/share/doc/PACKAGE/copyright``); neither do instructions on how to use a program (these should be in on-line documentation, where all the users can see them).
zh: 如果一个包有一条至关重要的信息要传递给用户（比如\“不要原样运行我，你必须先编辑以下配置文件，否则你的系统可能会发出格式错误的消息\”），它应该在 ``config`` 或 ``postinst`` 脚本中显示，并提示用户按回车键以确认消息。版权信息不算至关重要（它们存在于 ``/usr/share/doc/PACKAGE/copyright`` 中）；关于如何使用程序的说明也不是至关重要的（它们应该在数据文档中，所有用户都可以看到它们）。

en: Any necessary prompting should almost always be confined to the ``config`` or ``postinst`` script. If it is done in the ``postinst``, it should be protected with a conditional so that unnecessary prompting doesn't happen if a package's installation fails and the ``postinst`` is called with ``abort-upgrade``, ``abort-remove`` or ``abort-deconfigure``.
zh: 所有必要的提示几乎都应该局限于 ``config`` 或 ``postinst`` 脚本中。如果它是在 ``postinst`` 中完成的，那么它应该通过一个条件运算式得以保护，这样如果一个包安装失败并且 ``postinst`` 以 ``abort-upgrade`` ， ``abort-remove`` 或 ``abort-deconfigure`` 调用的话，不会出现不必要的提示。

en: A sample implementation of such a whitelist written for the Mailman mailing list management software is used for mailing lists hosted by https://alioth-lists.debian.net/.
zh: 为 Mailman 邮件列表管理软件编写的此类白名单的实施示例被用于由 https://alioth-lists.debian.net/ 托管的邮件列表。

en: The detailed procedure for gracefully orphaning a package can be found in the Debian Developer's Reference (see :ref:`s-related`).
zh: 关于得体地遗弃一个包的详细过程可在Debian开发者参考（参见 :ref:`s-related` ）中找到。

en: The blurb that comes with a program in its announcements and/or ``README`` files is rarely suitable for use in a description. It is usually aimed at people who are already in the community where the package is used.
zh: 程序在其公告和/或 ``README`` 文件中附带的简介很少适用于出现在描述中。它通常针对那些在使用该包的社群中的人。

en: Essential is needed in part to avoid unresolvable dependency loops on upgrade. If packages add unnecessary dependencies on packages in this set, the chances that there **will** be an unresolvable dependency loop caused by forcing these Essential packages to be configured first before they need to be is greatly increased. It also increases the chances that frontends will be unable to **calculate** an upgrade path, even if one exists.
zh: 我们之所以需要核心包部分上是为了避免升级时无法解决的依赖循环。如果一个软件包对这个集合中的包添加了不必要的依赖，那么强制这些核心包在尚未需要配置前被配置会大大增加其产生无法解决的依赖循环的可能性。它还增加了前端无法 **计算** 升级路径的可能性，即使这样的路径是存在的。

en: Also, functionality is rarely ever removed from the Essential set, but *packages* have been removed from the Essential set when the functionality moved to a different package. So depending on these packages *just in case* they stop being essential does way more harm than good.
zh: 此外，从核心包集合中删除功能的情况少之又少，但是当功能移至其他包时， *包* 是会从核心包集中被删除的。因此， *以防万一* 这些包不再是核心包而对它们进行依赖，弊远大于利。

en: Debconf or another tool that implements the Debian Configuration Management Specification will also be installed, and any versioned dependencies on it will be satisfied before preconfiguration begins.
zh: Debconf 或其他实现Debian配置管理规范的工具也会被安装，并且在预配置开始之前，所有对它的版本依赖都会被满足。
