developers-reference - en to ru translation catalogue (204 entries)

en: Best Packaging Practices
ru: Лучшие практики создания пакетов

en: This chapter provides some best practices for Debian developers. All recommendations are merely that, and are not requirements or policy. These are just some subjective hints, advice and pointers collected from Debian developers. Feel free to pick and choose whatever works best for you.
ru: Эта глава содержит описание некоторых лучших практик для разработчиков Debian. Все рекомендации являются только рекомендациями, а не требованиями или правилами. Они представляют собой лишь субъективные подсказки, советы и указания, позаимствованные у других разработчиков Debian. Выбирайте то, что лучше всего подходит именно вам.

en: Best practices for ``debian/rules``
ru: Лучшие практики для ``debian/rules``

en: Helper scripts
ru: Сценарии-помощники

en: The rationale for using helper scripts in ``debian/rules`` is that they let maintainers use and share common logic among many packages. Take for instance the question of installing menu entries: you need to put the file into ``/usr/share/menu`` (or ``/usr/lib/menu`` for executable binary menufiles, if this is needed), and add commands to the maintainer scripts to register and unregister the menu entries. Since this is a very common thing for packages to do, why should each maintainer rewrite all this on their own, sometimes with bugs? Also, supposing the menu directory changed, every package would have to be changed.
ru: Основная причина использования сценариев-помощников в файле ``debian/rules`` заключается в том, что последние позволяют сопровождающим распространять общую логику на множество пакетов и использовать её. Рассмотрим для примера вопрос установки пунктов меню: вам необходимо поместить файл в ``/usr/share/menu`` (или, если это требуется, ``/usr/lib/menu`` для выполняемых двоичных файлов меню), а также добавить команды сценариям сопровождающего для регистрации и отмены регистрации этих пунктов меню. Поскольку это довольно частая задача, зачем каждому сопровождающему переписывать всё это самостоятельно, а иногда и с ошибками? Кроме того, допустим, что каталог меню изменился, в этом случае пришлось бы изменить каждый пакет.

en: Helper scripts take care of these issues. Assuming you comply with the conventions expected by the helper script, the helper takes care of all the details. Changes in policy can be made in the helper script; then packages just need to be rebuilt with the new version of the helper and no other changes.
ru: Сценарии-помощники могут позаботиться об этих проблемах. Допустим, вы соблюдаете конвенции, ожидаемые сценарием-помощником, а последний заботится обо всех деталях. Если политика изменится, то это изменение может быть отражено в сценарии-помощнике; тогда пакеты нужно будет лишь собрать заново с новой версией помощника без каких-либо изменений вручную.

en: :ref:`tools` contains a couple of different helpers. The most common and best (in our opinion) helper system is ``debhelper``. Previous helper systems, such as ``debmake``, were monolithic: you couldn't pick and choose which part of the helper you found useful, but had to use the helper to do everything. ``debhelper``, however, is a number of separate little ``dh_*`` programs. For instance, ``dh_installman`` installs and compresses man pages, ``dh_installmenu`` installs menu files, and so on. Thus, it offers enough flexibility to be able to use the little helper scripts, where useful, in conjunction with hand-crafted commands in ``debian/rules``.
ru: :ref:`tools` содержит описание различных помощников. Наиболее часто используемой и лучшей (по нашему мнению) системой-помощником является ``debhelper``. Предшествующие системы-помощники, такие как ``debmake``, были монолитны: вы не могли выбрать только ту часть помощника, которая кажется вам полезной, вам приходилось использовать этот помощник для всего сразу. Тем не менее, ``debhelper`` представляет собой ряд отдельных небольших программ ``dh_*``. Например, ``dh_installman`` устанавливает и сжимает страницы руководства, ``dh_installmenu`` устанавливает файлы меню и так далее. Таким образом, этот помощник предлагает достаточный уровень гибкости, позволяющий использовать небольшие сценарии-помощники там, где это подходит, а также команды, добавленные в файл ``debian/rules`` вручную.

en: You can get started with ``debhelper`` by reading debhelper 1, and looking at the examples that come with the package. ``dh_make``, from the ``dh-make`` package (see :ref:`dh-make`), can be used to convert a vanilla source package to a ``debhelper``\ ized package. This shortcut, though, should not convince you that you do not need to bother understanding the individual ``dh_*`` helpers. If you are going to use a helper, you do need to take the time to learn to use that helper, to learn its expectations and behavior.
ru: Вы можете начать своё знакомство с ``debhelper`` с чтения debhelper 1 и изучения примеров, которые поставляются вместе с содержащим этот помощник пакетом. ``dh_make`` из пакета ``dh-make`` (см. :ref:`dh-make`), может использоваться для перевода ванильного пакета с исходным кодом в ``debhelper``\ ианизированый пакет. Этот короткий путь не должен, однако, создать у вас впечатление, что вам не нужно беспокоиться о понимании каждого отдельного помощника ``dh_*``. Если вы собираетесь использовать помощник, вам следует потратить время на изучение того, как этот помощник используется, и изучить его ожидания и поведение.

en: Multiple binary packages
ru: Множественные двоичные пакеты

en: The second case can be easily managed in ``debian/rules``. You just need to move the appropriate files from the build directory into the package's temporary trees. You can do this using ``install`` or ``dh_install`` from ``debhelper``. Be sure to check the different permutations of the various packages, ensuring that you have the inter-package dependencies set right in ``debian/control``.
ru: Со вторым случае можно легко управиться при помощи настроек в файле ``debian/rules``. Вам нужно лишь переместить соответствующие файлы из каталога сборки во временные деревья пакета. Вы можете сделать это при помощи команд ``install`` или ``dh_install`` из пакета ``debhelper``. Не забудьте проверить разные изменения различных пакетов на предмет того, что вы правильно установили межпакетные зависимости в файле ``debian/control``.

en: Best practices for ``debian/control``
ru: Лучшие практики для ``debian/control``

en: The following practices are relevant to the ``debian/control`` file. They supplement the `Policy on package descriptions <https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions>`__.
ru: Следующие практики относятся к файлу ``debian/control``. Они дополняют `Политику описаний пакетов <https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions>`__.

en: The description of the package, as defined by the corresponding field in the ``control`` file, contains both the package synopsis and the long description for the package. :ref:`bpp-desc-basics` describes common guidelines for both parts of the package description. Following that, :ref:`bpp-pkg-synopsis` provides guidelines specific to the synopsis, and :ref:`bpp-pkg-desc` contains guidelines specific to the description.
ru: Описание пакета, как оно определено в соответствующем поле файла ``control``, содержит резюме пакета и длинное описание этого пакета. :ref:`bpp-desc-basics` описывает общие принципы обеих этих частей описания пакета. Далее, :ref:`bpp-pkg-synopsis` содержит принципы, относящиеся к резюме, а :ref:`bpp-pkg-desc` представляет собой принципы, относящиеся к описанию.

en: General guidelines for package descriptions
ru: Общие принципы описания пакетов

en: The package description should be written for the average likely user, the average person who will use and benefit from the package. For instance, development packages are for developers, and can be technical in their language. More general-purpose applications, such as editors, should be written for a less technical user.
ru: Описание пакета должно быть написано для среднего пользователя, среднего человека, который будет использовать и извлекать пользу из данного пакета. Например, пакеты для разработки предназначены для разработчиков, и могут быть описаны техническим языком. Описания приложений общего назначения, таких как текстовые редакторы, должны быть написаны для менее подкованного в техническом плане пользователя.

en: Our review of package descriptions lead us to conclude that most package descriptions are technical, that is, are not written to make sense for non-technical users. Unless your package really is only for technical users, this is a problem.
ru: Наш обзор описаний пакетов привёл нас к заключению, что большая часть описаний пакетов являются техническими, то есть они не написаны так, чтобы быть понятными технически не подкованным пользователям. Если ваш пакет предназначен не только для технических пользователей, это является проблемой.

en: How do you write for non-technical users? Avoid jargon. Avoid referring to other applications or frameworks that the user might not be familiar with — GNOME or KDE is fine, since users are probably familiar with these terms, but GTK is probably not. Try not to assume any knowledge at all. If you must use technical terms, introduce them.
ru: Как следует писать описания для технически не подкованных пользователей? Избегайте жаргона. Избегайте указания на другие приложения или наборы приложений, которые могут быть незнакомы пользователю — GNOME или KDE это нормально, так как пользователи вероятно знакомы с этими терминами, но термин GTK скорее всего им не знаком. Попытайтесь вообще не допускать какого-либо знания. Если вам нужно использовать технические термины, определите их.

en: Be objective. Package descriptions are not the place for advocating your package, no matter how much you love it. Remember that the reader may not care about the same things you care about.
ru: Будьте объективны. Описания пакетов — это не то место, где следует пропагандировать свой пакет, не важно, насколько вы его любите. Помните, что читатель может и не заботиться о тех же вещах, что и вы.

en: References to the names of any other software packages, protocol names, standards, or specifications should use their canonical forms, if one exists. For example, use X Window System, X11, or X; not X Windows, X-Windows, or X Window. Use GTK, not GTK+ or gtk. Use GNOME, not Gnome. Use PostScript, not Postscript or postscript.
ru: Указания на названия любых других пакетов ПО, названия протоколов, стандартов или спецификаций должны иметь каноническую форму, если таковая существует. Например, используйте X Window System, X11 или X; но не X Windows, X-Windows или X Window. Используйте GTK, а не GTK+ или gtk. Используйте GNOME, а не Gnome. Используйте PostScript, а не Postscript или postscript.

en: If you are having problems writing your description, you may wish to send it along to ``debian-l10n-english@lists.debian.org`` and request feedback.
ru: Если у вас возникли проблемы с написанием описания, вы можете отправить его по адресу ``debian-l10n-english@lists.debian.org`` с запросом помощи.

en: The package synopsis, or short description
ru: Резюме пакета или короткое описание

en: Policy says the synopsis line (the short description) must be concise, not repeating the package name, but also informative.
ru: Политика говорит, что строка резюме (короткое описание) должна быть точной, не должна повторять имя пакета, но также должна быть информативной.

en: The synopsis functions as a phrase describing the package, not a complete sentence, so sentential punctuation is inappropriate: it does not need extra capital letters or a final period (full stop). It should also omit any initial indefinite or definite article — "a", "an", or "the". Thus for instance:
ru: Резюме представляет собой фразу, описывающую пакет, а не полное предложение, поэтому пунктуация, характерная для предложений, тут неуместна: дополнительные заглавные буквы или точка в конце (как знак полной остановки) не нужны. Также следует пропустить любой начальный неопределённый или определённый артикль — "a", "an" или "the". Таким образом, например:

en: Technically this is a noun phrase minus articles, as opposed to a verb phrase. A good heuristic is that it should be possible to substitute the package *name* and *synopsis* into this formula:
ru: Технически это именная фраза без артиклей в противоположность глагольной фразе. Хорошая эвристика состоит в том, что должно быть возможно подставить *имя* пакета вместо его *резюме* в следующую формулу:

en: The package *name* provides {a,an,the,some} *synopsis*.
ru: Пакет *имя пакета* предоставляет {a,an,the,some} *резюме пакета*.

en: Sets of related packages may use an alternative scheme that divides the synopsis into two parts, the first a description of the whole suite and the second a summary of the package's role within it:
ru: Наборы связанных пакетов могут использовать альтернативную схему, которая разделяет резюме на две части, на, во-первых, описание всего набора и, во-вторых, резюме роли конкретного пакета в этом наборе:

en: These synopses follow a modified formula. Where a package "*name*" has a synopsis "*suite* (*role*)" or "*suite* - *role*", the elements should be phrased so that they fit into the formula:
ru: Эти резюме следуют изменённой формуле. В ней пакет "*имя пакета*" имеет резюме "*набор пакетов* (*роль*)" или "*набор пакетов* - *роль*", элементы резюме должны быть сформулированы так, чтобы они подходили под следующую формулу:

en: The package *name* provides {a,an,the} *role* for the *suite*.
ru: Пакет *имя пакета* предоставляет {a,an,the} *роль* для *набора пакетов*.

en: The long description
ru: Длинное описание

en: The long description is the primary information available to the user about a package before they install it. It should provide all the information needed to let the user decide whether to install the package. Assume that the user has already read the package synopsis.
ru: Длинное описание является первичной информацией, доступной пользователю о пакете до того, как он его установит. Оно должно предоставлять всю информацию, которая необходима для того, чтобы пользователь мог решить устанавливать ему этот пакет или нет. Допускайте, что пользователь уже прочитал резюме пакета.

en: The long description should consist of full and complete sentences.
ru: Длинное описание должно состоять из полных и законченных предложений.

en: The first paragraph of the long description should answer the following questions: what does the package do? what task does it help the user accomplish? It is important to describe this in a non-technical way, unless of course the audience for the package is necessarily technical.
ru: Первый абзац длинного описания должен содержать ответ на следующие вопросы: кто делает этот пакет? какие задачи он помогает решить пользователю? Важно описать это без использования технических терминов, если, конечно, аудиторией данного пакета не являются с необходимостью технически подкованные пользователи.

en: Be careful to avoid spelling and grammar mistakes. Ensure that you spell-check it. Both ``ispell`` and ``aspell`` have special modes for checking ``debian/control`` files:
ru: Будьте внимательны, избегайте орфографических и грамматических ошибок. Проверьте описание на ошибки. И ``ispell``, и ``aspell`` имеют специальные режимы для проверки файлов ``debian/control``:

en: Users usually expect these questions to be answered in the package description:
ru: Обычно пользователи ожидают найти в описании пакета ответы на следующие вопросы:

en: What does the package do? If it is an add-on to another package, then the short description of the package we are an add-on to should be put in here.
ru: Что этот пакет делает? Если он является дополнением для другого пакета, то в описании следует поместить краткое описание того пакета, дополнением которого является данный пакет.

en: Why should I want this package? This is related to the above, but not the same (this is a mail user agent; this is cool, fast, interfaces with PGP and LDAP and IMAP, has features X, Y, and Z).
ru: Почему я хочу получить этот пакет? Ответ на этот вопрос связан с ответом на предыдущий вопрос, но это разные вопросы (это клиент электронной почты; он классный, быстрый, работает с PGP и LDAP, а также с IMAP, он имеет X, Y и Z).

en: If this package should not be installed directly, but is pulled in by another package, this should be mentioned.
ru: Если этот пакет не должен быть установлен напрямую, но тянется за другим пакетом, это обстоятельство должно быть явно указано.

en: If the package is ``experimental``, or there are other reasons it should not be used, if there are other packages that should be used instead, it should be here as well.
ru: Если пакет является ``экспериментальным``, либо имеются другие причины, по которым этот пакет не следуем использовать, если имеются другие пакеты, которые следует использовать вместо данного, это также должно быть отдельно указано.

en: Upstream home page
ru: Домашняя страница основной ветки разработки

en: We recommend that you add the URL for the package's home page in the ``Homepage`` field of the ``Source`` section in ``debian/control``. Adding this information in the package description itself is considered deprecated.
ru: Мы рекомендуем вам добавить ссылку на домашнюю страницу пакета в поле ``Homepage`` раздела ``Source`` в файле ``debian/control``. Добавление этой информации в само описание пакета считается устаревшей нормой.

en: Version Control System location
ru: Размещение системы контроля версий

en: There are additional fields for the location of the Version Control System in ``debian/control``.
ru: В файле ``debian/control`` имеются дополнительные поля для указания размещения системы контроля версий.

en: The information is meant to be useful for the final user, willing to browse the latest work done on the package (e.g. when looking for the patch fixing a bug tagged as ``pending`` in the bug tracking system).
ru: Подразумевается, что данная информация будет полезна для конечного пользователя, который захочет ознакомиться с последней работой, связанной с этим пакетом (напр., захочет найти заплату для исправления ошибки, обозначенной с системе отслеживания ошибок тегом ``pending``).

en: The information is meant to be useful for a user knowledgeable in the given Version Control System and willing to build the current version of a package from the VCS sources. Other uses of this information might include automatic building of the latest VCS version of the given package. To this end the location pointed to by the field should better be version agnostic and point to the main branch (for VCSs supporting such a concept). Also, the location pointed to should be accessible to the final user; fulfilling this requirement might imply pointing to an anonymous access of the repository instead of pointing to an SSH-accessible version of the same.
ru: Подразумевается, что эта информация будет полезна пользователю, которых осведомлён о принципах работы данной системы управления версиями и желает собрать текущую версию пакета из исходного кода, размещённого там. Другие способы использования этой информации могут включать автоматическую сборку последней версии данного пакета из системы управления версиями. Для этого размещение, указанное в данном поле, не должно иметь привязку к версии и должно указывать на основную ветку (это касается систем управления версиями, поддерживающих эту возможность). Кроме того, указываемое размещение должно быть доступно конечному пользователю; для выполнения этого требования может потребоваться указание на анонимный доступ к репозиторию вместо указания версии, доступной через SSH.

en: Best practices for ``debian/changelog``
ru: Лучшие практики для ``debian/changelog``

en: The following practices supplement the `Policy on changelog files <https://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs>`__.
ru: Следующие практики дополняют `Политику о файлах изменений <https://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs>`__.

en: Writing useful changelog entries
ru: Написание полезных пунктов файла изменений

en: The changelog entry for a package revision documents changes in that revision, and only them. Concentrate on describing significant and user-visible changes that were made since the last version.
ru: Записи в файле изменений ревизии пакета описывают изменения данной ревизии и только их. Сосредоточьтесь на описании существенных и заметных для пользователя изменений, которые были произведены с момента выпуска последней версии.

en: Focus on *what* was changed — who, how and when are usually less important. Having said that, remember to politely attribute people who have provided notable help in making the package (e.g., those who have sent in patches).
ru: Обратите внимание на то, *что* было изменено — кто, как и когда обычно менее важно. Указав это, не забудьте вежливо указать людей, которые оказали заметную помощь в создании пакета (напр., тех, что выслал заплаты).

en: There's no need to elaborate the trivial and obvious changes. You can also aggregate several changes in one entry. On the other hand, don't be overly terse if you have undertaken a major change. Be especially clear if there are changes that affect the behaviour of the program. For further explanations, use the ``README.Debian`` file.
ru: Нет необходимости указывать тривиальные и очевидные изменения. Также вы можете объединять несколько изменений в одну запись. С другой стороны, не будьте чересчур кратки, если внесли крупное изменение. Будьте особенно ясны, если были произведены изменения, которые оказывают влияние на поведение программы. Для указания дальнейших объяснений используйте файл ``README.Debian``.

en: Use common English so that the majority of readers can comprehend it. Avoid abbreviations, tech-speak and jargon when explaining changes that close bugs, especially for bugs filed by users that did not strike you as particularly technically savvy. Be polite, don't swear.
ru: Используйте общепринятый вариант английского языка, чтобы большинство читателей смогли вас понять. Избегайте аббревиатур, технического языка и жаргона, когда вы описываете изменения, закрывающие ошибки, особенно это касается ошибок, о которых сообщили пользователи, и которые не кажутся вам в каком-то особом смысле технически сложными. Будьте вежливы, не ругайтесь.

en: It is sometimes desirable to prefix changelog entries with the names of the files that were changed. However, there's no need to explicitly list each and every last one of the changed files, especially if the change was small or repetitive. You may use wildcards.
ru: Иногда желательно указать в начале записи об изменениях имена файлов, которые были изменены. Тем не менее, нет необходимости явно указывать каждый изменённый файл, особенно если изменения были небольшими или повторяющимися. Используйте шаблоны с метасимволами.

en: When referring to bugs, don't assume anything. Say what the problem was, how it was fixed, and append the closes: #nnnnn string. See :ref:`upload-bugfix` for more information.
ru: Если вы ссылаетесь на ошибки, не предполагайте у пользователей какого-либо знания. Сообщите, в чём заключалась проблема, как она была исправлена, и добавьте строку closes: #nnnnn. Дополнительную информацию см. в :ref:`upload-bugfix`.

en: Common misconceptions about changelog entries
ru: Распространённые неправильные представления о записях об изменениях

en: The changelog entries should **not** document generic packaging issues (Hey, if you're looking for foo.conf, it's in /etc/blah/.), since administrators and users are supposed to be at least remotely acquainted with how such things are generally arranged on Debian systems. Do, however, mention if you change the location of a configuration file.
ru: Записи об изменениях **не** должны описывать общие проблемы при создании пакета (Эй, если вы ищете foo.conf, он находится в /etc/бла-бла-бла/.), поскольку предполагается, что администраторы и пользователи по меньшей мере отдалённо знакомы с тем, как такие вещи обычно улаживаются в системах Debian. Сообщите, тем не менее, о том, что вы изменили расположение файла настройки, если вы произвели такое изменение.

en: The only bugs closed with a changelog entry should be those that are actually fixed in the same package revision. Closing unrelated bugs in the changelog is bad practice. See :ref:`upload-bugfix`.
ru: Единственными закрываемыми с помощью записей об изменениях ошибками должны быть те, которые фактически исправляются именно в этой ревизии пакета. Закрытие несвязанных ошибок в журнале изменений является плохой практикой. См. :ref:`upload-bugfix`.

en: The changelog entries should **not** be used for random discussion with bug reporters (I don't see segfaults when starting foo with option bar; send in more info), general statements on life, the universe and everything (sorry this upload took me so long, but I caught the flu), or pleas for help (the bug list on this package is huge, please lend me a hand). Such things usually won't be noticed by their target audience, but may annoy people who wish to read information about actual changes in the package. See :ref:`bug-answering` for more information on how to use the bug tracking system.
ru: Записи об изменениях **не** должны использоваться для случайных дискуссий с теми, кто сообщил об ошибках (Я не наблюдаю ошибки сегментирования, когда запускаю foo с опцией bar; вышлите дополнительную информацию), общих утверждений о жизни, Вселенной и вообще (извините, загрузка этой версии заняла так много времени, но у меня была простуда), или просьб о помощи (список ошибок этого пакета очень велик, пожалуйста, помогите мне с этим). Скорее всего всё это не будет замечено целевой аудиторией, но может надоедать тем людям, которые хотят читать информацию о фактических изменениях в пакете. Подробную информацию о том, как использовать систему отслеживания ошибок см. в :ref:`bug-answering`.

en: It is an old tradition to acknowledge bugs fixed in non-maintainer uploads in the first changelog entry of the proper maintainer upload. As we have version tracking now, it is enough to keep the NMUed changelog entries and just mention this fact in your own changelog entry.
ru: Традиционно ошибки, исправленные в загрузках, которые произведены не сопровождающими, упоминаются в первой записи об изменениях той загрузки, которая произведена собственно сопровождающим. Поскольку сейчас у нас имеется система отслеживания версий, достаточно сохранить записи об изменениях, сделанных несопровождающими, и просто упомянуть этот факт в вашей записи об изменениях.

en: Common errors in changelog entries
ru: Общие ошибки в записях об изменениях

en: The following examples demonstrate some common errors or examples of bad style in changelog entries.
ru: Следующие примеры демонстрируют некоторых общие ошибки или примеры плохого стиля в записях об изменениях.

en: This doesn't tell readers anything too useful, obviously.
ru: Очевидно, эта запись не сообщает читателям ничего полезного.

en: What was the patch about?
ru: Что это была за заплата?

en: Overhaul which accomplished what? Is the mention of late night supposed to remind us that we shouldn't trust that code?
ru: Что это была за переделка? Упоминание поздней ночи предполагается как сообщение о том, что этому коду не следует доверять?

en: First of all, there's absolutely no need to upload the package to convey this information; instead, use the bug tracking system. Secondly, there's no explanation as to why the report is not a bug.
ru: Во-первых, вовсе не нужно загружать пакет, чтобы сообщить эту информацию; вместо этого используйте систему отслеживания ошибок. Во-вторых, отсутствует объяснение того, почему данный отчет об ошибке ошибкой не является.

en: Where's the description? If you can't think of a descriptive message, start by inserting the title of each different bug.
ru: Где описание? Если вы не можете придумать описание, начните со вставки заголовка каждой отдельной ошибки.

en: Supplementing changelogs with ``NEWS.Debian`` files
ru: Дополнение журналов файлами ``NEWS.Debian``

en: Important news about changes in a package can also be put in ``NEWS.Debian`` files. The news will be displayed by tools like ``apt-listchanges``, before all the rest of the changelogs. This is the preferred means to let the user know about significant changes in a package. It is better than using ``debconf`` notes since it is less annoying and the user can go back and refer to the ``NEWS.Debian`` file after the install. And it's better than listing major changes in ``README.Debian``, since the user can easily miss such notes.
ru: Важные новости об изменениях в пакете можно также поместить в файл ``NEWS.Debian``. Новости будут отображены такими инструментами как ``apt-listchanges`` до всех остальных журналов изменений. Это является предпочтительным способом сообщения пользователям о существенных изменениях в пакете. Это лучше, чем использование примечаний ``debconf``, поскольку этот способ менее надоедлив и пользователь может вернуться и просмотреть файл ``NEWS.Debian`` после установки. И это лучше, чем указание крупных изменений в файле ``README.Debian``, поскольку пользователь легко может не заметить вашего сообщения.

en: The file format is the same as a debian changelog file, but leave off the asterisks and describe each news item with a full paragraph when necessary rather than the more concise summaries that would go in a changelog. It's a good idea to run your file through ``dpkg-parsechangelog`` to check its formatting as it will not be automatically checked during build as the changelog is. Here is an example of a real ``NEWS.Debian`` file:
ru: Формат этот файла такой же как и формат файла журнала изменений, но забудьте о звёздочках и описывайте каждую новость в отдельном полном параграфе, если это необходимо, вместо того, чтобы давать более краткие резюме, которые подходят для журнала изменений. Хорошо бы пропустить ваш файл через ``dpkg-parsechangelog`` для проверки форматирования, поскольку в отличии от журнала изменений он не будет проверен автоматически во время сборки. Ниже приведён пример настоящего файла ``NEWS.Debian``:

en: The ``NEWS.Debian`` file is installed as ``/usr/share/doc/``\ *package*\ ``/NEWS.Debian.gz``. It is compressed, and always has that name even in Debian native packages. If you use ``debhelper``, ``dh_installchangelogs`` will install ``debian/NEWS`` files for you.
ru: Файл ``NEWS.Debian`` устанавливается как ``/usr/share/doc/``\ *пакет*\ ``/NEWS.Debian.gz``. Он сжимается, и он всегда имеет данное имя даже в родных пакетах Debian. Если вы используете ``debhelper``, ``dh_installchangelogs`` установит файлы ``debian/NEWS`` за вас.

en: Unlike changelog files, you need not update ``NEWS.Debian`` files with every release. Only update them if you have something particularly newsworthy that user should know about. If you have no news at all, there's no need to ship a ``NEWS.Debian`` file in your package. No news is good news!
ru: В отличии от файлов журналов вам не нужно обновлять файлы ``NEWS.Debian`` в каждом выпуске. Обновляйте их только если имеется что-то действительно заслуживающее упоминания, что должно быть известно пользователю. Если у вас нет никаких новостей, не нужно добавлять файл ``NEWS.Debian`` в ваш пакет. Отсутствие новостей — уже хорошие новости!

en: Best practices for maintainer scripts
ru: Лучшие практики для сценариев сопровождающих

en: Maintainer scripts must be idempotent. That means that you need to make sure nothing bad will happen if the script is called twice where it would usually be called once.
ru: Сценарии сопровождающего должны быть идемпотентны. Это означает, что вам следует убедиться, что не произойдёт ничего плохого в том случае, когда сценарий будет вызван дважды, хотя обычно он вызывается только один раз.

en: Standard input and output may be redirected (e.g. into pipes) for logging purposes, so don't rely on them being a tty.
ru: Стандартные ввод и вывод могут быть перенаправлены (напр., конвейерами) с целью записи журнала для отладки, поэтому вам не следует считать, что они представляют собой лишь tty.

en: All prompting or interactive configuration should be kept to a minimum. When it is necessary, you should use the ``debconf`` package for the interface. Remember that prompting in any case can only be in the ``configure`` stage of the ``postinst`` script.
ru: Все подсказки и интерактивные настройки должны быть сведены к минимуму. Когда это необходимо, для предоставления интерфейса следует использовать пакет ``debconf``. Помните, что подсказки в любом случае могут быть выведены лишь на этапе ``настройки`` сценария ``postinst``.

en: Keep the maintainer scripts as simple as possible. We suggest you use pure POSIX shell scripts. Remember, if you do need any bash features, the maintainer script must have a bash shebang line. POSIX shell or Bash are preferred to Perl, since they enable ``debhelper`` to easily add bits to the scripts.
ru: Делайте сценарии сопровождающего насколько простыми, насколько это возможно. Мы предлагаем использовать чистые сценарии оболочки POSIX. Помните, если вам нужны какие-либо возможности bash, сценарий сопровождающего должен содержать строку, объявляющую использование bash. Оболочка POSIX или Bash предпочтительны по отношению к Perl, поскольку они позволяют ``debhelper`` легко добавлять что-то новое в эти сценарии.

en: If you change your maintainer scripts, be sure to test package removal, double installation, and purging. Be sure that a purged package is completely gone, that is, it must remove any files created, directly or indirectly, in any maintainer script.
ru: Если вы изменяете ваши сценарии сопровождающего, проверьте удаление пакета, двойную установку и очистку. Убедитесь, что очищенный пакет убран полностью, то есть, очистка должна удалить любые напрямую или косвенно созданные любым сценарием сопровождающего файлы.

en: If you need to check for the existence of a command, you should use something like
ru: Если вам необходимо проверить существование команды, используйте что-то вроде этого:

en: Configuration management with ``debconf``
ru: Управление настройкой с помощью ``debconf``

en: Debconf is a great tool but it is often poorly used. Many common mistakes are listed in the debconf-devel 7 man page. It is something that you must read if you decide to use debconf. Also, we document some best practices here.
ru: Debconf является превосходным инструментом, но часто он плохо используется. Многие общие ошибки приведены на странице руководства debconf-devel 7. Вам следует прочитать это руководство, если вы решили использовать debconf. Кроме этого, здесь мы приводим ниже лучшие практики использования этого инструмента.

en: These guidelines include some writing style and typography recommendations, general considerations about debconf usage as well as more specific recommendations for some parts of the distribution (the installation system for instance).
ru: Эти принципы включают некоторые рекомендации по типографии и стилю письма, общие соображения об использовании debconf, а также более конкретные рекомендации для некоторых частей дистрибутива (например, системы установки).

en: Do not abuse debconf
ru: Не злоупотребляйте debconf

en: Since debconf appeared in Debian, it has been widely abused and several criticisms received by the Debian distribution come from debconf abuse with the need of answering a wide bunch of questions before getting any little thing installed.
ru: Поскольку debconf возник в Debian, им часто злоупотребляют, и дистрибутив Debian получил изрядную долю критики за злоупотребление debconf необходимостью отвечать на большое количество вопросов для установки даже очень небольшого пакета.

en: General recommendations for authors and translators
ru: Общие рекомендации для авторов и переводчиков

en: Write correct English
ru: Пишите на правильном английском

en: Most Debian package maintainers are not native English speakers. So, writing properly phrased templates may not be easy for them.
ru: Большинство сопровождающих Debian не являются носителями английского языка. Поэтому написание правильно сформулированных шаблонов может быть для них нелегким делом.

en: Please use (and abuse) ``debian-l10n-english@lists.debian.org`` mailing list. Have your templates proofread.
ru: Используйте список рассылки ``debian-l10n-english@lists.debian.org`` (и злоупотребляйте им). Пусть ваши шаблоны будут вычитаны.

en: Badly written templates give a poor image of your package, of your work... or even of Debian itself.
ru: Плохо написанные шаблоны создают плохое представление о вашем пакете, вашей работе... и даже самом Debian.

en: Avoid technical jargon as much as possible. If some terms sound common to you, they may be impossible to understand for others. If you cannot avoid them, try to explain them (use the extended description). When doing so, try to balance between verbosity and simplicity.
ru: Избегайте технического жаргона насколько это возможно. Если некоторые термины звучат знакомо для вам, они всё равно могут быть непонятны остальным. Если вы не можете избежать этих терминов, попытайтесь объяснить их (используйте подробное описание). Если вы пишете описание, пытайтесь балансировать на грани подробности и простоты.

en: Be kind to translators
ru: Будьте добры к переводчикам

en: Please use gettext-based templates. Install ``po-debconf`` on your development system and read its documentation (``man po-debconf`` is a good start).
ru: Используйте шаблоны на основе gettext. Установите ``po-debconf`` в вашу систему, используемую для разработки, и прочтите документацию этого пакета (``man po-debconf`` является хорошим началом).

en: If you plan to do changes to your original templates, please use the notification system provided with the ``po-debconf`` package, namely the ``podebconf-report-po``, to contact translators. Most active translators are very responsive and getting their work included along with your modified templates will save you additional uploads. If you use gettext-based templates, the translator's name and e-mail addresses are mentioned in the PO files headers and will be used by ``podebconf-report-po``.
ru: Если вы планируете изменить ваши оригинальные шаблоны, для связи с переводчиками используйте систему оповещения, предоставляемую пакетом ``po-debconf``, а именно ``podebconf-report-po``. Наиболее активные переводчики очень отзывчивы, и включение их работы вместе с вашими изменёнными шаблонами позволит избежать вам дополнительных загрузок. Если вы используете шаблоны на основе gettext, имя переводчика и его адрес электронной почты указаны в заголовках PO-файлов и будут использоваться командой ``podebconf-report-po``.

en: A recommended use of that utility is:
ru: Рекомендованное использование этой утилиты:

en: Giving a deadline to translators is always appreciated, so that they can organize their work. Please remember that some translation teams have a formalized translate/review process and a delay lower than 10 days is considered as unreasonable. A shorter delay puts too much pressure on translation teams and should be kept for very minor changes.
ru: Всегда ценится точный срок, отведённый для работы над переводом, чтобы переводчики могли организовать свою работу. Помните, что некоторые команды переводчиков используют формализованный процесс перевода/проверки, и задержка менее 10 дней считается чрезвычайно короткой. Более короткая задержка слишком сильно давит на команды переводчиков и должна устанавливаться только для очень небольших изменений.

en: If in doubt, you may also contact the translation team for a given language (debian-l10n-xxxxx@lists.debian.org), or the ``debian-i18n@lists.debian.org`` mailing list.
ru: Если у вас возникли сомнения, вы также можете связаться с командой перевода данного языка (debian-l10n-xxxxx@lists.debian.org) или списком рассылки ``debian-i18n@lists.debian.org``.

en: Unfuzzy complete translations when correcting typos and spelling
ru: Отменяйте статус неясных строк когда исправляете опечатки или орфографию

en: When the text of a debconf template is corrected and you are **sure** that the change does **not** affect translations, please be kind to translators and *unfuzzy* their translations.
ru: Когда текст шаблона debconf был изменён, и вы **уверены**, что это изменение **не** влияет на переводы, будьте добры по отношению к переводчикам и *отмените статус неясных строк* для их переводов.

en: If you don't do so, the whole template will not be translated as long as a translator will send you an update.
ru: Если вы не сделаете этого, весь шаблон не будет переведён пока переводчик не вышлет вам обновление.

en: To *unfuzzy* translations, you can use ``msguntypot`` (part of the ``po4a`` package).
ru: Чтобы *отменить статус неясных строк* для переводов, вы можете использовать ``msguntypot`` (часть пакета ``po4a``).

en: Regenerate the POT and PO files.
ru: Создание файлов POT и PO заново.

en: Make a copy of the POT file.
ru: Создание копии POT-файла.

en: Make a copy of all the PO files.
ru: Создание копии всех PO-файлов.

en: Change the debconf template files to fix the typos.
ru: Изменение файлов шаблона debconf для исправления ошибок.

en: Regenerate the POT and PO files (again).
ru: Создание файлов POT и PO заново (опять).

en: At this point, the typo fix fuzzied all the translations, and this unfortunate change is the only one between the PO files of your main directory and the one from the fridge. Here is how to solve this.
ru: Сейчас исправление опечатки привело к тому, что все переводы были отмечены как неясные, и это несчастное изменение является единственным различием между файлами PO вашего основного каталога и сохранёнными во временном каталоге файлами. Вот как решить эту проблема.

en: Discard fuzzy translation, restore the ones from the fridge.
ru: Отбросьте неясный перевод, восстановите перевод из сохранённых во временном каталоге файлов.

en: Manually merge the PO files with the new POT file, but taking the useless fuzzy into account.
ru: Вручную слейте файлы PO с новым POT-файлов, но учтите бесполезные неясности.

en: Clean up.
ru: Очистите.

en: Do not make assumptions about interfaces
ru: Не допускайте ничего по поводу интерфейсов

en: String templates should also avoid mentioning the default values in their description. First, because this is redundant with the values seen by the users. Also, because these default values may be different from the maintainer choices (for instance, when the debconf database was preseeded).
ru: Строки шаблонов должны также избегать в своём описании упоминания значений по умолчанию. Во-первых, это излишне, так как значения видны пользователям. Также это излишне потому, что значения по умолчанию могут различаться в зависимости от выбора сопровождающего (например, когда база данных debconf была автоматизирована).

en: More generally speaking, try to avoid referring to user actions. Just give facts.
ru: Вообще говоря, попытайтесь избежать указания на действия пользователя. Просто представляйте факты.

en: Do not use first person
ru: Не используйте первое лицо

en: Be gender neutral
ru: Будьте нейтральны в гендерном отношении

en: Templates fields definition
ru: Определение полей шаблонов

en: This part gives some information which is mostly taken from the debconf-devel 7 manual page.
ru: Эта часть содержит информацию, которая по большей части заимствована из страницы руководства debconf-devel 7.

en: Type
ru: Тип

en: Results in a free-form input field that the user can type any string into.
ru: Создаёт поле свободного ввода, в которое пользователь может ввести любую строку.

en: Prompts the user for a password. Use this with caution; be aware that the password the user enters will be written to debconf's database. You should probably clean that value out of the database as soon as is possible.
ru: Запрашивает у пользователя пароль. Используйте с осторожностью; помните, что пароль, вводимый пользователем, будет записан в базу данных debconf. Вероятно, вам следует как можно скорее очистить это значение в базе данных.

en: A true/false choice. Remember: true/false, **not yes/no**...
ru: Выбор истинно/ложно. Помните: истинно/ложно, **а не да/нет**...

en: A choice between one of a number of values. The choices must be specified in a field named 'Choices'. Separate the possible values with commas and spaces, like this: ``Choices: yes, no, maybe``.
ru: Выбор одного значения из нескольких предложенных. Выбор должен быть определён в поле с именем 'Choices'. Разделите возможные значения запятыми и пробелами, например так: ``Choices: yes, no, maybe``.

en: If choices are translatable strings, the 'Choices' field may be marked as translatable by using ``__Choices``. The double underscore will split out each choice in a separate string.
ru: Если варианты выбора представляют собой переводимые строки, поле 'Choices' может быть отмечено как переводимое так: ``__Choices``. Двойное подчёркивание выделит каждый вариант выбора в отдельную строку.

en: The ``po-debconf`` system also offers interesting possibilities to only mark **some** choices as translatable. Example:
ru: Также система ``po-debconf`` предлагает интересные возможности для отметки только **некоторых** вариантов выбора в качестве переводимых. Пример:

en: In that example, only the 'Other' string is translatable while others are acronyms that should not be translated. The above allows only 'Other' to be included in PO and POT files.
ru: В этом примере только строка 'Other' является переводимой, остальные же представляют собой акронимы, которые не нужно переводить. Этот пример разрешает включение в файлы PO и POT только варианта 'Other'.

en: The debconf templates flag system offers many such possibilities. The po-debconf 7 manual page lists all these possibilities.
ru: Система флагов для шаблонов debconf предлагает множество таких возможностей. В странице руководства po-debconf 7 приведены все эти возможности.

en: Like the select data type, except the user can choose any number of items from the choices list (or chose none of them).
ru: Подобен типу данных select, но пользователь может выбрать любое число вариантов из списка вариантов (или не выбрать ни один из них).

en: Rather than being a question per se, this datatype indicates a note that can be displayed to the user. It should be used only for important notes that the user really should see, since debconf will go to great pains to make sure the user sees it; halting the install for them to press a key, and even mailing the note to them in some cases.
ru: Этот тип данных не является вопросом самим по себе, а представляет собой примечание, которое может быть показано пользователю. Он должен использоваться только для важных примечаний, которые пользователи действительно должны заметить, поскольку debconf приложит максимум усилий для гарантии того, что пользователь заметит это примечание; установка будет остановлена до нажатия клавиши, в некоторых случаях пользователю будет даже выслано это примечание по почте.

en: This type is now considered obsolete: don't use it.
ru: Данный тип считается устаревшим: не используйте его.

en: It is recommended to use this type for any message that needs user attention for a correction of any kind.
ru: Рекомендуется использовать этот тип для любых сообщений, не которые необходимо обратить внимание пользователя для внесения исправлений любого вида.

en: Description: short and extended description
ru: Описание: краткое и расширенное описания

en: Template descriptions have two parts: short and extended. The short description is in the Description: line of the template.
ru: Описания шаблонов имеют две части: краткую и расширенную. Краткое описание даётся в строке Description: данного шаблона.

en: The short description should be kept short (50 characters or so) so that it may be accommodated by most debconf interfaces. Keeping it short also helps translators, as usually translations tend to end up being longer than the original.
ru: Краткое описание должно быть коротким (50 символов или около того), чтобы оно могло быть обработано большинством интерфейсов debconf. Краткое описание также помогает переводчикам, поскольку переводы обычно длиннее оригиналов.

en: The short description does not necessarily have to be a full sentence. This is part of the keep it short and efficient recommendation.
ru: Краткое описание не обязательно должно быть полным предложением. Это лишь часть, она должна быть краткой и эффективной рекомендацией.

en: The extended description should not repeat the short description word for word. If you can't think up a long description, then first, think some more. Post to debian-devel. Ask for help. Take a writing class! That extended description is important. If after all that you still can't come up with anything, leave it blank.
ru: Расширенное описание не должно слово в слово повторять краткое описание. Если вы не можете придумать длинное описание, то для начала подумайте ещё. Напишите в debian-devel. Попросите помощи. Прослушайте курс письма! Расширенное описание очень важно. Если в конце концов вы всё еще не можете ничего придумать, оставьте его пустым.

en: The extended description should use complete sentences. Paragraphs should be kept short for improved readability. Do not mix two ideas in the same paragraph but rather use another paragraph.
ru: Расширенное описание должно состоять из полных предложений. Параграфы должны быть короткими и удобочитаемыми. Не смешивайте две идеи в одном параграфе, лучше разделите их на два.

en: Don't be too verbose. User tend to ignore too long screens. 20 lines are by experience a border you shouldn't cross, because that means that in the classical dialog interface, people will need to scroll, and lot of people just don't do that.
ru: Не будьте слишком подробны. Пользователи обычно игнорируют слишком длинные экраны. По опыту, 20 строк — это та граница, которую вам не следует пересекать, поскольку это означает, что в классическом диалоговом интерфейсе придётся прокручивать экран, а большинство пользователей этого просто не делают.

en: The extended description should **never** include a question.
ru: Расширенное описание **никогда** не должно включать в себя вопрос.

en: For specific rules depending on templates type (string, boolean, etc.), please read below.
ru: Для ознакомления с конкретными правилами, зависящими от типа шаблона (string, boolean и т. д.), прочтите нижеследующий текст.

en: This field is optional. It contains the default answer for string, select and multiselect templates. For multiselect templates, it may contain a comma-separated list of choices.
ru: Это поле опционально. Оно содержит ответ по умолчанию для шаблонов string, select и multiselect. Для шаблонов multiselect это поле может содержать список вариантов выбора, разделённых запятыми.

en: Type field
ru: Тип поля

en: No specific indication except: use the appropriate type by referring to the previous section.
ru: Без конкретного указания за исключением следующего: используйте соответствующий тип из предыдущего раздела.

en: Description field
ru: Поле Description

en: Below are specific instructions for properly writing the Description (short and extended) depending on the template type.
ru: Ниже приведены конкретные инструкции для правильного написания Description (краткого и расширенного описаний) в зависимости от типа шаблона.

en: String/password templates
ru: Шаблоны string/password

en: The short description is a prompt and **not** a title. Avoid question style prompts (IP Address?) in favour of opened prompts (IP address:). The use of colons is recommended.
ru: Краткое описание является приглашением, а **не** заголовком. Избегайте приглашений в виде вопросов (IP Address?) в пользу открытых приглашений (IP address:). Рекомендуется использовать двоеточие.

en: The extended description is a complement to the short description. In the extended part, explain what is being asked, rather than ask the same question again using longer words. Use complete sentences. Terse writing style is strongly discouraged.
ru: Расширенное описание дополняет краткое описание. В расширенной части объясните пользователю, что спрашивается, а не задавайте ему тот же вопрос при помощи более длинных слов. Используйте полные предложения. Краткие стиль письма крайне не рекомендуется.

en: Boolean templates
ru: Шаблоны boolean

en: Again, please avoid referring to specific interface widgets. A common mistake for such templates is if you answer Yes-type constructions.
ru: Опять же, избегайте обращения к конкретным виджетам интерфейса. Частой ошибкой таких шаблонов являются ответы на конструкции Да-типа.

en: Select/Multiselect
ru: select/multiselect

en: The extended description will complete the short description. It may refer to the available choices. It may also mention that the user may choose more than one of the available choices, if the template is a multiselect one (although the interface often makes this clear).
ru: Расширенное описание должно заканчивать краткое описание. Оно может отсылать к доступным вариантам выбора. Также оно может содержать напоминание о том, что пользователь может выбрать более одного варианта из доступных, если выбран шаблон multiselect (хотя интерфейс обычно делает это очевидными).

en: Notes
ru: Примечания

en: The short description should be considered to be a **title**.
ru: Краткое описание должно рассматриваться как **заголовок**.

en: The extended description is what will be displayed as a more detailed explanation of the note. Phrases, no terse writing style.
ru: Расширенное описание представляет собой то, что будет отображено в качестве более подробного объяснения данного примечания. Фразы, подробный стиль письма.

en: Choices field
ru: Поле Choices

en: If the Choices are likely to change often, please consider using the \__Choices trick. This will split each individual choice into a single string, which will considerably help translators for doing their work.
ru: Если скорее всего поле Choices будет часто меняться, попробуйте использовать трюк \__Choices. Так каждый индивидуальный выбор будет выделен в отдельную строку, что поможет переводчикам делать их работу.

en: Default field
ru: Поле Default

en: Example, taken from the geneweb package templates:
ru: Пример, взятый из шаблонов пакета geneweb:

en: Internationalization
ru: Интернационализация

en: Handling debconf translations
ru: Обработка переводов debconf

en: Like porters, translators have a difficult task. They work on many packages and must collaborate with many different maintainers. Moreover, most of the time, they are not native English speakers, so you may need to be particularly patient with them.
ru: Подобно тем, кто занимается переносами, перед переводчиками стоит сложная задача. Они работают над многими пакетами и должны сотрудничать с большим количеством разных сопровождающих. Более того, по большей части они не являются носителями английского языка, поэтому вам следует быть с ними особенно вежливыми.

en: Using ``po-debconf``, the translation is stored in ``.po`` files (drawing from ``gettext`` translation techniques). Special template files contain the original messages and mark which fields are translatable. When you change the value of a translatable field, by calling ``debconf-updatepo``, the translation is marked as needing attention from the translators. Then, at build time, the ``dh_installdebconf`` program takes care of all the needed magic to add the template along with the up-to-date translations into the binary packages. Refer to the po-debconf 7 manual page for details.
ru: При использовании ``po-debconf``, перевод сохраняется в файлах ``.po`` (формате, извлечённом из ``gettext``). Специальные файлы шаблонов содержат оригинальные сообщения и пометки для тех полей, которые могут быть переведены. Когда вы изменяете значение поля, которое может быть переведено, вызывая команду ``debconf-updatepo``, перевод отмечается как требующий внимания переводчиков. Тогда, во время сборки, программа ``dh_installdebconf`` заботится обо всей требуемой магии по добавлению шаблона вместе с обновлёнными переводами в двоичные пакеты. За подробностями обратитесь к странице руководства po-debconf 7.

en: Internationalized documentation
ru: Интернационализованная документация

en: Internationalizing documentation is crucial for users, but a lot of labor. There's no way to eliminate all that work, but you can make things easier for translators.
ru: Интернационализация документации очень важна для пользователей, но требует большого труда. Не существует способа сделать так, чтобы не нужно было делать эту работу, но вы можете упростить её для переводчиков.

en: Common packaging situations
ru: Общие ситуации при создании пакетов

en: Packages using ``autoconf``/``automake``
ru: Пакеты, использующие ``autoconf``/``automake``

en: Keeping ``autoconf``'s ``config.sub`` and ``config.guess`` files up to date is critical for porters, especially on more volatile architectures. Some very good packaging practices for any package using ``autoconf`` and/or ``automake`` have been synthesized in ``/usr/share/doc/autotools-dev/README.Debian.gz`` from the ``autotools-dev`` package. You're strongly encouraged to read this file and to follow the given recommendations.
ru: Поддержка файлов ``autoconf`` ``config.sub`` и ``config.guess`` в актуальном состоянии является критической задачей для тех, кто занимается переносом, особенно на более волатильные архитектуры. Некоторые очень хорошие практики по созданию пакетов для любого пакета, использующего ``autoconf`` и/или ``automake`` были синтезированы в ``/usr/share/doc/autotools-dev/README.Debian.gz`` из пакета ``autotools-dev`` package. Настойчиво рекомендуем прочитать этот файл и следовать приведённым в нём рекомендациям.

en: Libraries
ru: Библиотеки

en: Libraries are always difficult to package for various reasons. The policy imposes many constraints to ease their maintenance and to make sure upgrades are as simple as possible when a new upstream version comes out. Breakage in a library can result in dozens of dependent packages breaking.
ru: По ряду причина для библиотек всегда трудно создавать пакеты. Политика налагает множество ограничений для облегчения из сопровождения и для того, чтобы гарантировать, что обновления будут настолько просты, насколько это возможно, когда выходит новая версия из основной ветки разработки. Поломка в библиотеке может вызвать поломку множества зависимых пакетов.

en: Documentation
ru: Документация

en: Be sure to follow the `Policy on documentation <https://www.debian.org/doc/debian-policy/ch-docs.html>`__.
ru: Обязательно пройдите по ссылке `Политика документации <https://www.debian.org/doc/debian-policy/ch-docs.html>`__.

en: If your package contains documentation built from XML or SGML, we recommend you not ship the XML or SGML source in the binary package(s). If users want the source of the documentation, they should retrieve the source package.
ru: Если ваш пакет содержит документацию, собираемую из XML или SGML, рекомендуем вам не добавлять исходный код в форматах XML или SGML в двоичный пакет (-ы). Если пользователи захотят получить исходный код документации, им следует загрузить пакет с исходным кодом.

en: Policy specifies that documentation should be shipped in HTML format. We also recommend shipping documentation in PDF and plain text format if convenient and if output of reasonable quality is possible. However, it is generally not appropriate to ship plain text versions of documentation whose source format is HTML.
ru: Политика определяет, что документация должна поставляться в формате HTML. Мы также рекомендуем поставлять документацию в формате PDF и в виде обычного текста, если это удобно, и если возможно обеспечить вывод достаточного качества. Тем не менее, предоставление документации, исходным форматом которой является HTML, в виде обычного текста не является подходящим.

en: Major shipped manuals should register themselves with ``doc-base`` on installation. See the ``doc-base`` package documentation for more information.
ru: Крупные руководства должны при установке регистрироваться в ``doc-base``. Дополнительную информацию см. в документации пакета ``doc-base``.

en: Debian policy (section 12.1) directs that manual pages should accompany every program, utility, and function, and suggests them for other objects like configuration files. If the work you are packaging does not have such manual pages, consider writing them for inclusion in your package, and submitting them upstream.
ru: Политика Debian (раздел 12.1) указывает, что справочные страницы должны поставляться со всякой программой, утилитой и функцией, и предлагает поставку справочных страниц для других объектов, таких как файлы настройки. Если та работа, для которой вы создаёте пакеты, не имеет таких справочных страниц, постарайтесь написать их самостоятельно для включения в ваш пакет и отправки в основную ветку разработки.

en: Specific types of packages
ru: Конкретные типы пакетов

en: Several specific types of packages have special sub-policies and corresponding packaging rules and practices:
ru: Некоторые конкретные типы пакетов имеют свои специальные подполитики и соответствующие правила и практики создания пакетов:

en: Emacs related packages have the `emacs policy <https://www.debian.org/doc/packaging-manuals/debian-emacs-policy>`__.
ru: Связанные с Emacs пакеты имеют `Политику Emacs <https://www.debian.org/doc/packaging-manuals/debian-emacs-policy>`__.

en: Java related packages have their `java policy <https://www.debian.org/doc/packaging-manuals/java-policy/>`__.
ru: Связанные с Java пакеты имеют свою `Политику Java <https://www.debian.org/doc/packaging-manuals/java-policy/>`__.

en: Packages providing XML or SGML DTDs should conform to the recommendations found in the ``sgml-base-doc`` package.
ru: Пакеты, предоставляющие XML или SGML DTD должны соответствовать рекомендациям из пакета ``sgml-base-doc``.

en: Lisp packages should register themselves with ``common-lisp-controller``, about which see ``/usr/share/doc/common-lisp-controller/README.packaging``.
ru: Пакеты Lisp должны регистрироваться в ``common-lisp-controller``, об этом см. ``/usr/share/doc/common-lisp-controller/README.packaging``.

en: Architecture-independent data
ru: Независящие от архитектуры данные

en: It is not uncommon to have a large amount of architecture-independent data packaged with a program. For example, audio files, a collection of icons, wallpaper patterns, or other graphic files. If the size of this data is negligible compared to the size of the rest of the package, it's probably best to keep it all in a single package.
ru: Добавление большого количества независящих от архитектуры данных в пакеты с программами не является в каком бы то ни было смысле необычным явлением при создании пакетов. Например, аудио файлы, наборы иконок, шаблоны обоев рабочего стола или другие графические файлы. Если размер этих данных незначителен по сравнению с размером остального пакета, возможно лучшим решением будет сохранение всех данных в одном пакете.

en: Needing a certain locale during build
ru: Необходимость в конкретной локали во время сборки

en: If you need a certain locale during build, you can create a temporary file via this trick:
ru: Если вам требуется определённая локаль во время сборки, вы можете создать временный файл с помощью следующих команд:

en: If you set ``LOCPATH`` to the equivalent of ``/usr/lib/locale``, and ``LC_ALL`` to the name of the locale you generate, you should get what you want without being root. Something like this:
ru: Если вы установите ``LOCPATH`` значение, эквивалентное ``/usr/lib/locale``, а значение ``LC_ALL`` будет имя той локали, которую вы создаёте, у вас будет то, что вам нужно при работе из-за учётной записи суперпользователя. Что-то вроде этого:

en: Make transition packages deborphan compliant
ru: Делаем так, чтобы deborphan определят переходные пакеты

en: Deborphan is a program for helping users to detect which packages can safely be removed from the system, i.e. the ones that have no packages depending on them. The default operation is to search only within the libs and oldlibs sections, to hunt down unused libraries. But when passed the right argument, it tries to catch other useless packages.
ru: deborphan — программам, помогающая пользователям определить то, какие пакеты могут быть безопасно удалены из системы, т. е. те, от которых не зависит более ни один пакет. По умолчанию поиск осуществляется только в разделах libs и oldlibs для обнаружения неиспользуемых библиотек. Но когда вы передали этой программе необходимых аргумент, она пытается найти все бесполезные пакеты.

en: Best practices for ``.orig.tar.{gz,bz2,xz}`` files
ru: Лучшие практики для файлов ``.orig.tar.{gz,bz2,xz}``

en: There are two kinds of original source tarballs: Pristine source and repackaged upstream source.
ru: Существует два вида оригинальных tar-архивов с исходным кодом: чистый исходный код и запакованный заново исходный код основной ветки разработки.

en: Pristine source
ru: Чистый исходный код

en: The defining characteristic of a pristine source tarball is that the ``.orig.tar.{gz,bz2,xz}`` file is byte-for-byte identical to a tarball officially distributed by the upstream author. [1]_ This makes it possible to use checksums to easily verify that all changes between Debian's version and upstream's are contained in the Debian diff. Also, if the original source is huge, upstream authors and others who already have the upstream tarball can save download time if they want to inspect your packaging in detail.
ru: Определяющей характеристикой чистого tar-архива с исходным кодом является то, что файл ``.orig.tar.{gz,bz2,xz}`` побайтово идентичен tar-архиву, который официальной распространялся автором основной ветки разработки. [1]_ Это позволяет использовать контрольные суммы для простой проверки, что все изменения между версией Debian и версией основной ветки содержаться в db=iff-файле Debian. Кроме того, если оригинальный исходный код имеет большой размер, авторы основной ветки разработки и другие, кто уже имеют tar-архив из основной ветки, могут сохранить время, затрачиваемое на скачивание, в том случае, если они хотят подробно проверить ваш пакет.

en: It unpacks the tarball in an empty temporary directory by doing
ru: Он распаковывает tar-архив в пустой временный каталог, выполняя

en: If, after this, the temporary directory contains nothing but one directory and no other files, ``dpkg-source`` renames that directory to *packagename*\ ``-``\ *upstream-version*\ ``(.orig)``. The name of the top-level directory in the tarball does not matter, and is forgotten.
ru: Если после этого временный каталог не содержит ничего кроме одного каталога и не содержит других файлов, ``dpkg-source`` переименовывает этот каталог в *имяпакета*\ ``-``\ *версия-основной-ветки*\ ``(.orig)``. Имя каталога верхнего уровня в tar-архиве не имеет значения и просто забывается.

en: Otherwise, the upstream tarball must have been packaged without a common top-level directory (shame on the upstream author!). In this case, ``dpkg-source`` renames the temporary directory *itself* to *packagename*\ ``-``\ *upstream-version*\ ``(.orig)``.
ru: В противном случае, tar-архив основной ветки должен быть запакован без общего каталога верхнего уровня (позор автору основной ветки!). В этом случае ``dpkg-source`` переименовывает *самостоятельно* временный каталог в *имяпакета*\ ``-``\ *версия-основной-ветки*\ ``(.orig)``.

en: Repackaged upstream source
ru: Повторная упаковка исходного кода основной ветки

en: You **should** upload packages with a pristine source tarball if possible, but there are various reasons why it might not be possible. This is the case if upstream does not distribute the source as gzipped tar at all, or if upstream's tarball contains non-DFSG-free material that you must remove before uploading.
ru: Вы **должны** загружать пакеты с чистым исходным кодом, если это возможно, но имеются причины, по которым это может быть невозможно. Это имеет место, когда основная ветка вообще не поставляет исходный код в виде сжатого при помощи gzip tar-архива, либо если tar-архив основной ветки содержит не свободный в соответствии с критериями DFSG материал, который вам следует удалить до момента осуществления загрузки.

en: In these cases the developer must construct a suitable ``.orig.tar.{gz,bz2,xz}`` file themselves. We refer to such a tarball as a repackaged upstream source. Note that a repackaged upstream source is different from a Debian-native package. A repackaged source still comes with Debian-specific changes in a separate ``.diff.gz`` or ``.debian.tar.{gz,bz2,xz}`` and still has a version number composed of *upstream-version* and *debian-version*.
ru: В этих случаях разработчик должен создать подходящий файл ``.orig.tar.{gz,bz2,xz}`` самостоятельно. Мы говорим о таком tar-архиве как о запакованном заново исходном коде основной ветки. Заметьте, что запакованный заново исходный код основной ветки отличается от родного пакета Debian. Запакованный заново исходный код содержит специфичные для Debian изменения в отдельных файлах ``.diff.gz`` или ``.debian.tar.{gz,bz2,xz}`` и всё ещё имеет номер версии, составленный из *версия-основной-ветки* и *версия-debian*.

en: There may be cases where it is desirable to repackage the source even though upstream distributes a ``.tar.{gz,bz2,xz}`` that could in principle be used in its pristine form. The most obvious is if *significant* space savings can be achieved by recompressing the tar archive or by removing genuinely useless cruft from the upstream archive. Use your own discretion here, but be prepared to defend your decision if you repackage source that could have been pristine.
ru: Возможны такие случаи, когда желательно запаковать исходный код заново, даже несмотря на то, что основная ветка разработки поставляет ``.tar.{gz,bz2,xz}``, который в принципе может использовать в его чистой форме. Наиболее очевидным случаем является ситуация, когда может быть достигнута *значительная* экономия места путём повторной упаковки tar-архива или путём удаления действительно ненужного хлама из архива основной ветки. Используйте это на своё усмотрение, но будьте готовы защищать своё решение, если вы запаковали заново исходный код, которые мог бы быть чистым.

en: A repackaged ``.orig.tar.{gz,bz2,xz}``
ru: Запакованный заново ``.orig.tar.{gz,bz2,xz}``

en: **should not** contain any file that does not come from the upstream author(s), or whose contents has been changed by you. [2]_
ru: **не должен** содержать какие-либо файлы, которые получены не от авторов основной ветки разработки, или содержание которых было изменено вами. [2]_

en: (*Rationale:* It is common for Debian users who need to build software for non-Debian platforms to fetch the source from a Debian mirror rather than trying to locate a canonical upstream distribution point).
ru: (*Обоснование:* Обычно пользователи Debian, желающие собрать ПО для отличных от Debian платформ, загружают исходный код с зеркала Debian, а не пытаются найти каноничный выпуск основной ветки разработки).

en: Changing binary files
ru: Изменение двоичных файлов

en: Best practices for debug packages
ru: Лучшие практики для отладочных пакетов

en: Note that the debug package should depend on the package that it provides debugging symbols for, and this dependency should be versioned. For example:
ru: Заметьте, отладочный пакет должен зависеть от пакета, для которого он предоставляет отладочные символы, и эта зависимость должна быть зависимостью от конкретной версии. Например:

en: Best practices for meta-packages
ru: Лучшие практики для метапакетов

en: A meta-package is a mostly empty package that makes it easy to install a coherent set of packages that can evolve over time. It achieves this by depending on all the packages of the set. Thanks to the power of APT, the meta-package maintainer can adjust the dependencies and the user's system will automatically get the supplementary packages. The dropped packages that were automatically installed will be also be marked as removal candidates (and are even automatically removed by ``aptitude``). ``gnome`` and ``linux-image-amd64`` are two examples of meta-packages (built by the source packages ``meta-gnome2`` and ``linux-latest``).
ru: Метапакет обычно является пустым пакетом, который облегчает установку связанного набора пакетов, которые со временем могут развиваться. Это достигается благодаря тому, что метапакет зависит от всех пакетов данного набора. Благодаря мощи APT, сопровождающий метапакета может изменять зависимости, и пользовательская система будет автоматически получать дополнительные пакеты. Кроме того, отброшенные пакеты, которые были установлены автоматически, будут помечены как кандидаты на удаление (и даже будут автоматически удалены с помощью ``aptitude``). ``gnome`` и ``linux-image-amd64`` являются примерами метапакетов (собранных из пакетов с исходным кодом ``meta-gnome2`` и ``linux-latest``).
