0 - en to ru-RU translation catalogue (121 entries)

en: Backport
ru-RU: Бэкпортирование

en: Rebuild
ru-RU: Пересборка

en: Source package
ru-RU: Пакет исходных кодов

en: Archive
ru-RU: Архив

en: Meta-package
ru-RU: Метапакет

en: Debian Developer
ru-RU: Разработчик Debian

en: Maintainer
ru-RU: Сопровождающий

en: Creating a Debian Package
ru-RU: Создание пакета Debian

en: It is quite common, for an administrator who has been handling Debian packages in a regular fashion, to eventually feel the need to create their own packages, or to modify an existing package. This chapter aims to answer the most common questions in this field, and provide the required elements to take advantage of the Debian infrastructure in the best way. With any luck, after trying your hand for local packages, you may even feel the need to go further than that and join the Debian project itself!
ru-RU: Нередко администратор, постоянно имеющий дело с пакетами Debian, со временем чувствует необходимость в создании своих собственных пакетов или изменении существующего пакета. Цель этой главы состоит в том, чтобы ответить на наиболее распространенные вопросы в этой области, а также предоставить необходимые базовые знания для использования инфраструктуры Debian наилучшим образом. Если повезет, после попытки приложить руку к созданию локальных пакетов вы даже можете почувствовать потребность в том, чтобы пойти дальше и присоединиться к самому Проекту Debian!

en: Rebuilding a Package from its Sources
ru-RU: Пересборка пакета из его исходного кода

en: Rebuilding a binary package is required under several sets of circumstances. In some cases, the administrator needs a software feature that requires the software to be compiled from sources, with a particular compilation option; in others, the software as packaged in the installed version of Debian is not recent enough. In the latter case, the administrator will usually build a more recent package taken from a newer version of Debian — such as <emphasis role="distribution">Testing</emphasis> or even <emphasis role="distribution">Unstable</emphasis> — so that this new package works in their <emphasis role="distribution">Stable</emphasis> distribution; this operation is called “backporting”. As usual, care should be taken, before undertaking such a task, to check whether it has been done already — a quick look on the Debian Package Tracker for that package will reveal that information. <ulink type="block" url="https://tracker.debian.org/" /> <indexterm><primary>backport</primary></indexterm>
ru-RU: Пересборка двоичного пакета требуется при ряде обстоятельств. В некоторых случаях администратору нужна функциональность программы, для активации которой необходима компиляция из исходного кода с определенной опцией; в других программное обеспечение, упакованное в установленной версии Debian, недостаточно актуально. В последнем случае администратору обычно нужно собрать более свежий пакет, взятый из более новой версии Debian — например <emphasis role="distribution">Testing</emphasis> или даже <emphasis role="distribution">Unstable</emphasis> — чтобы новый пакет заработал в дистрибутиве <emphasis role="distribution">Stable</emphasis>; эта операция называется «бэкпортирование». Как обычно, прежде чем приступать к такой задаче, следует проверить, не был ли такой пакет уже создан, — для этого достаточно беглого взгляда на страницу данного пакета в Системе отслеживания пакетов Debian. <ulink type="block" url="https://tracker.debian.org/" /> <indexterm><primary>бэкпорт</primary></indexterm>

en: Getting the Sources
ru-RU: Получение исходного кода

en: Making Changes
ru-RU: Внесение изменений

en: Let us use the <emphasis role="pkg">samba</emphasis> package as an example.
ru-RU: Для примера возьмём пакет <emphasis role="pkg">samba</emphasis>.

en: The last command invokes a text editor (<command>sensible-editor</command> — this should be your favorite editor if it is mentioned in the <varname>VISUAL</varname> or <varname>EDITOR</varname> environment variables, and the default editor otherwise) to allow documenting the differences brought by this rebuild. This editor shows us that <command>dch</command> really did change the <filename>debian/changelog</filename> file.
ru-RU: Последняя команда вызывает текстовый редактор (<command>sensible-editor</command> — это должен быть ваш любимый редактор, если он указан в переменной окружения <varname>VISUAL</varname> или <varname>EDITOR</varname>, а в противном случае редактор по умолчанию) для того, чтобы документировать изменения, внесенные данной пересборкой. Этот редактор показывает нам, что <command>dch</command> действительно изменила файл <filename>debian/changelog</filename>.

en: Depending on the local changes to the packages, an update may also be required in the <filename>debian/control</filename> file, which contains a description of the generated packages. In particular, this file contains <literal>Build-Depends</literal> lines controlling the list of dependencies that must be fulfilled at package build time. These often refer to versions of packages contained in the distribution the source package comes from, but which may not be available in the distribution used for the rebuild. There is no automated way to determine if a dependency is real or only specified to guarantee that the build should only be attempted with the latest version of a library — this is the only available way to force an <emphasis>autobuilder</emphasis> to use a given package version during build, which is why Debian maintainers frequently use strictly versioned build-dependencies.
ru-RU: В зависимости от локальных изменений в пакетах может потребоваться также обновление файла <filename>debian/control</filename>, который содержит описание создаваемых пакетов. В частности, этот файл содержит строки <literal>Build-Depends</literal>, контролирующие список зависимостей, которые должны быть удовлетворены на этапе сборки пакета. Они часто ссылаются на версии пакетов, содержащиеся в дистрибутиве, откуда взят исходный код, но которые могут быть недоступны в дистрибутиве, используемом для пересборки. Не существует автоматизированного способа определить, является ли зависимость реальной, или же она указана только с целью гарантировать выполнение сборки исключительно с последней версией библиотеки, — это единственный доступный способ заставить <emphasis>autobuilder</emphasis> использовать данную версию пакета во время сборки, из-за чего сопровождающие Debian часто используют строго версионированые сборочные зависимости.

en: If you know for sure that these build-dependencies are too strict, you should feel free to relax them locally. Reading the files which document the standard way of building the software — these files are often called <filename>INSTALL</filename> — will help you figure out the appropriate dependencies. Ideally, all dependencies should be satisfiable from the distribution used for the rebuild; if they are not, a recursive process starts, whereby the packages mentioned in the <literal>Build-Depends</literal> field must be backported before the target package can be. Some packages may not need backporting, and can be installed as-is during the build process (a notable example is <emphasis role="pkg">debhelper</emphasis>). Note that the backporting process can quickly become complex if you are not careful. Therefore, backports should be kept to a strict minimum when possible.
ru-RU: Если вы точно знаете, что эти сборочные зависимости слишком строги, не стесняйтесь ослабить их локально. Чтение файлов, документирующих стандартный способ сборки программного обеспечения — эти файлы часто называют <filename>INSTALL</filename> — поможет выяснить соответствующие зависимости. В идеале все зависимости должны быть удовлетворены из дистрибутива, используемого для пересборки; в противном случае начинается рекурсивный процесс, в результате которого пакеты, упомянутые в поле <literal>Build-Depends</literal>, должны быть бэкпортированы раньше целевого пакета. Некоторые пакеты могут не требовать бэкпортирования, и их можно установить как есть в процессе сборки (ярким примером является <emphasis role="pkg">debhelper</emphasis>). Обратите внимание, что процесс бэкпортирования может стать лавинообразным, если вы не будете осторожны. Поэтому бэкпорты должны быть сведены к абсолютному минимуму, насколько это возможно.

en: <emphasis>TIP</emphasis> Installing <literal>Build-Depends</literal>
ru-RU: <emphasis>СОВЕТ</emphasis> Установка <literal>Build-Depends</literal>

en: Starting the Rebuild
ru-RU: Запуск пересборки

en: When all the needed changes have been applied to the sources, we can start generating the actual binary package (<filename>.deb</filename> file). The whole process is managed by the <command>dpkg-buildpackage</command> command.
ru-RU: Когда все необходимые изменения внесены в исходный код, мы можем запустить создание собственно двоичного пакета (файл <filename>.deb</filename>). Весь процесс управляется командой <command>dpkg-buildpackage</command>.

en: Rebuilding a package
ru-RU: Пересборка пакета

en: <emphasis>TOOL</emphasis> <command>fakeroot</command>
ru-RU: <emphasis>ИНСТРУМЕНТ</emphasis> <command>fakeroot</command>

en: In essence, the package creation process is a simple matter of gathering in an archive a set of existing (or built) files; most of the files will end up being owned by <emphasis>root</emphasis> in the archive. However, building the whole package under this user would imply increased risks; fortunately, this can be avoided with the <command>fakeroot</command> command. This tool can be used to run a program and give it the impression that it runs as <emphasis>root</emphasis> and creates files with arbitrary ownership and permissions. When the program creates the archive that will become the Debian package, it is tricked into creating an archive containing files marked as belonging to arbitrary owners, including <emphasis>root</emphasis>. This setup is so convenient that <command>dpkg-buildpackage</command> uses <command>fakeroot</command> by default when building packages.
ru-RU: В сущности процесс создания пакета является простым сбором в архив набора существующих (или скомпилированных) файлов; большинство файлов архива будут иметь в конечном итоге владельца <emphasis>root</emphasis>. Тем не менее, сборка всего пакета от имени этого пользователя подразумевала бы повышенный риск; к счастью, этого можно избежать с помощью команды <command>fakeroot</command>. Этот инструмент может быть использован для запуска программы и создания у неё впечатления, что она запущена от имени <emphasis>root</emphasis> и создает файлы с произвольным владельцем и правами. Когда программа создает архив, который станет пакетом Debian, она хитрым образом внедряется в процесс создания архива, содержащего файлы, помеченные как принадлежащие произвольным владельцам, в том числе <emphasis>root</emphasis>. Это поведение настолько удобно, что <command>dpkg-buildpackage</command> использует <command>fakeroot</command> по умолчанию при сборке пакетов.

en: Note that the program is only tricked into “believing” that it operates as a privileged account, and the process actually runs as the user running <command>fakeroot <replaceable>program</replaceable></command> (and the files are actually created with that user's permissions). At no time does it actually get root privileges that it could abuse.
ru-RU: Заметьте, что программу только заставляют «поверить» в то, что она работает под привилегированной учетной записью, но процесс на самом деле выполняется от имени пользователя, запустившего <command>fakeroot <replaceable>программа</replaceable></command> (и права на создаваемые файлы в действительности принадлежат этому пользователю). Фактически программа ни в какой момент времени не получает привилегий суперпользователя, которыми могла бы злоупотреблять.

en: Building your First Package
ru-RU: Сборка вашего первого пакета

en: Meta-Packages or Fake Packages
ru-RU: Метапакеты или пакеты-пустышки

en: Fake packages and meta-packages are similar, in that they are empty shells that only exist for the effects their meta-data have on the package handling stack.
ru-RU: Пакеты-пустышки и метапакеты схожи тем, что являются пустыми оболочками, существующими лишь ради эффектов, которые их метаданные оказывают на стек работы с пакетами.

en: The purpose of a fake package is to trick <command>dpkg</command> and <command>apt</command> into believing that some package is installed even though it is only an empty shell. This allows satisfying dependencies on a package when the corresponding software was installed outside the scope of the packaging system. Such a method works, but it should still be avoided whenever possible, since there is no guarantee that the manually installed software behaves exactly like the corresponding package would and other packages depending on it would not work properly.
ru-RU: Назначение пакета-пустышки состоит в том, чтобы обманом заставить <command>dpkg</command> и <command>apt</command> поверить в то, что какой-либо пакет установлен, даже если он пуст. Это позволяет удовлетворить зависимость от пакета, когда соответствующее программное обеспечение было установлено в обход системы управления пакетами. Хотя такой способ работает, его следует по возможности избегать, ведь нет никакой гарантии, что установленное вручную программное обеспечение ведет себя точно так же, как соответствующий пакет, и зависящие от него пакеты могут работать некорректно.

en: On the other hand, a meta-package exists mostly as a collection of dependencies, so that installing the meta-package will actually bring in a set of other packages in a single step.
ru-RU: Наоборот, метапакет представляет собой прежде всего набор зависимостей, так что установка метапакета в действительности предоставит целый набор других пакетов разом.

en: Both these kinds of packages can be created by the <command>equivs-control</command> and <command>equivs-build</command> commands (in the <emphasis role="pkg">equivs</emphasis> package). The <command>equivs-control <replaceable>file</replaceable></command> command creates a Debian package header file that should be edited to contain the name of the expected package, its version number, the name of the maintainer, its dependencies, and its description. Other fields without a default value are optional and can be deleted. The <literal>Copyright</literal>, <literal>Changelog</literal>, <literal>Readme</literal> and <literal>Extra-Files</literal> fields are not standard fields in Debian packages; they only make sense within the scope of <command>equivs-build</command>, and they will not be kept in the headers of the generated package.
ru-RU: Оба эти типа пакетов могут быть созданы командами <command>equivs-control</command> и <command>equivs-build</command> (из пакета <emphasis role="pkg">equivs</emphasis>). Команда <command>equivs-control <replaceable>файл</replaceable></command> создает заголовочный файл пакета Debian, который следует отредактировть таким образом, чтобы в нём содержалось название неоходимого пакета, номер его версии, имя сопровождающего, зависимости и описание. Прочие поля без значения по умолчанию являются необязательными и их можно удалить. Поля <literal>Copyright</literal>, <literal>Changelog</literal>, <literal>Readme</literal> и <literal>Extra-Files</literal> являются нестандартными в пакетах Debian; они имеют смысл только в рамках <command>equivs-build</command> и не будут сохранены в заголовках созданного пакета.

en: Header file of the <emphasis>libxml-libxml-perl</emphasis> fake package
ru-RU: Заголовочный файл пакета-пустышки <emphasis>libxml-libxml-perl</emphasis>

en: The next step is to generate the Debian package with the <command>equivs-build <replaceable>file</replaceable></command> command. Voilà: the package is created in the current directory and it can be handled like any other Debian package would.
ru-RU: Следующий шаг состоит в том, чтобы создать пакет Debian с помощью команды <command>equivs-build <replaceable>файл</replaceable></command>. Voilà: пакет создан в текущем каталоге и с ним можно работать, как с любым другим пакетом Debian.

en: Simple File Archive
ru-RU: Простое файловое хранилище

en: The Falcot Corp administrators need to create a Debian package in order to ease deployment of a set of documents on a large number of machines. The administrator in charge of this task first reads the “New Maintainer's Guide”, then starts working on their first package. <ulink type="block" url="https://www.debian.org/doc/manuals/maint-guide/" />
ru-RU: Администраторам Falcot Corp необходимо создать пакет для того, чтобы облегчить развёртывание набора документов на большом количестве машин. Администратор, отвечающий за эту задачу, сперва читает «Руководство начинающего разработчика Debian», после чего начинает работать над своим первым пакетом. <ulink type="block" url="https://www.debian.org/doc/manuals/maint-guide/" />

en: The first step is creating a <filename>falcot-data-1.0</filename> directory to contain the target source package. The package will logically, be named <literal>falcot-data</literal> and bear the <literal>1.0</literal> version number. The administrator then places the document files in a <filename>data</filename> subdirectory. Then they invoke the <command>dh_make</command> command (from the <emphasis role="pkg">dh-make</emphasis> package) to add files required by the package generation process, which will all be stored in a <filename>debian</filename> subdirectory:
ru-RU: Первым шагом является создание каталога <filename>falcot-data-1.0</filename> для целевого пакета исходного кода. Пакет, логично, будет называться <literal>falcot-data</literal> и иметь номер версии <literal>1.0</literal>. Затем администратор размещает файлы документов в подкаталоге <filename>data</filename>. После этого вызывается команда <command>dh_make</command> (из пакета <emphasis role="pkg">dh-make</emphasis>) для того, чтобы добавить файлы, необходимые для создания пакета, которые будут сохранены в подкаталоге <filename>debian</filename>:

en: <primary>package</primary><secondary>types</secondary>
ru-RU: <primary>пакет</primary><secondary>типы</secondary>

en: The <emphasis>library</emphasis> type corresponds to a source package leading to several binary packages. It is useful for shared libraries, since they need to follow strict packaging rules.
ru-RU: Тип <emphasis>library</emphasis> соответствует пакету исходного кода, из которого получается несколько двоичных пакетов. Он полезен для разделяемых библиотек, так как они должны следовать строгим правилам пакетирования.

en: <emphasis>TIP</emphasis> Maintainer's name and email address
ru-RU: <emphasis>СОВЕТ</emphasis> Имя и электронный адрес сопровождающего

en: Most of the programs involved in package maintenance will look for your name and email address in the <varname>DEBFULLNAME</varname> and <varname>DEBEMAIL</varname> or <varname>EMAIL</varname> environment variables. Defining them once and for all will avoid you having to type them multiple times. If your usual shell is <command>bash</command>, it is a simple matter of adding the following two lines in your <filename>~/.bashrc</filename> file (you will obviously replace the values with more relevant ones!):
ru-RU: Большинство программ, участвующих в сопровождении пакета, будет искать ваше имя и адрес электронной почты в переменных окружения <varname>DEBFULLNAME</varname> и <varname>DEBEMAIL</varname> или <varname>EMAIL</varname>. Их определение раз и навсегда избавит вас от необходимости многократно вводить их. Если вашей обычной оболочкой является <command>bash</command>, просто добавьте следующие две строки в ваш файл <filename>~/.bashrc</filename> (вам, разумеется, стоит заменить значения на более актуальные!):

en: The <filename>control</filename> file
ru-RU: Файл <filename>control</filename>

en: The <filename>changelog</filename> file
ru-RU: Файл <filename>changelog</filename>

en: The <filename>copyright</filename> file
ru-RU: Файл <filename>copyright</filename>

en: <emphasis>BACK TO BASICS</emphasis> <filename>Makefile</filename> file
ru-RU: <emphasis>К ОСНОВАМ</emphasis> Файл <filename>Makefile</filename>

en: A <filename>Makefile</filename> file is a script used by the <command>make</command> program; it describes rules for how to build a set of files from each other in a tree of dependencies (for instance, a program can be built from a set of source files). The <filename>Makefile</filename> file describes these rules in the following format:
ru-RU: Файл <filename>Makefile</filename> является сценарием, используемым программой <command>make</command>; он описывает правила для сборки набора файлов один из другого в соответствии с деревом зависимостей (к примеру, программа может быть собрана из набора файлов с исходным кодом). Файл <filename>Makefile</filename> описывает эти правила в следующем формате:

en: Note that the command lines must start with a tab character; also note that when a command line starts with a dash character (<literal>-</literal>), failure of the command does not interrupt the whole process.
ru-RU: Обратите внимание, что строки команд должны начинаться с символа табуляции; также стоит отметить, что когда командная строка начинается с дефиса (<literal>-</literal>), неудачное завершение команды не прерывает весь процесс.

en: The <filename>rules</filename> file usually contains a set of rules used to configure, build and install the software in a dedicated subdirectory (named after the generated binary package). The contents of this subdirectory is then archived within the Debian package as if it were the root of the filesystem. In our case, files will be installed in the <filename>debian/falcot-data/usr/share/falcot-data/</filename> subdirectory, so that installing the generated package will deploy the files under <filename>/usr/share/falcot-data/</filename>. The <filename>rules</filename> file is used as a <filename>Makefile</filename>, with a few standard targets (including <literal>clean</literal> and <literal>binary</literal>, used respectively to clean the source directory and generate the binary package).
ru-RU: Файл <filename>rules</filename> обычно содержит набор правил, используемых для конфигурирования, сборки и установки программного обеспечения в выделенный подкаталог (названный именем собранного двоичного пакета). Содержимое этого подкаталога затем архивируется в пакет Debian, как если бы это был корневой каталог файловой системы. В нашем случае файлы будут установлены в подкаталог <filename>debian/falcot-data/usr/share/falcot-data/</filename>, чтобы установка созданного пакета развернула файлы в <filename>/usr/share/falcot-data/</filename>. Файл <filename>rules</filename> используется в качестве <filename>Makefile</filename> с несколькими стандартными целями (включая <literal>clean</literal> и <literal>binary</literal>, используемые соответственно для очистки каталога с исходным кодом и создания двоичного пакета).

en: Although this file is the heart of the process, it increasingly contains only the bare minimum for running a standard set of commands provided by the <command>debhelper</command> tool. Such is the case for files generated by <command>dh_make</command>. To install our files, we simply configure the behavior of the <command>dh_install</command> command by creating the following <filename>debian/falcot-data.install</filename> file:
ru-RU: Хотя этот файл является центральным во всём процессе, он содержит лишь самый минимум для запуска стандартного набора команд, предоставляемых инструментом <command>debhelper</command>. Так обстоит дело с файлами, созданными с помощью <command>dh_make</command>. Чтобы установить наши файлы, мы просто настроим поведение команды <command>dh_install</command>, создав следующий файл <filename>debian/falcot-data.install</filename>:

en: At this point, the package can be created. We will, however, add a lick of paint. Since the administrators want the documents to be easily accessed from the menus of graphical desktop environments, we add a <filename>falcot-data.desktop</filename> file and get it installed in <filename>/usr/share/applications</filename> by adding a second line to <filename>debian/falcot-data.install</filename>.
ru-RU: Теперь пакет может быть создан. Однако, мы добавим несколько косметических штрихов. Поскольку администраторы хотят, чтобы документы были легко доступны из меню графического рабочего стола, мы добавим файл <filename>falcot-data.desktop</filename>, установим в <filename>/usr/share/applications</filename>, добавив вторую строчку в <filename>debian/falcot-data.install</filename>.

en: The <filename>falcot-data.desktop</filename> file
ru-RU: Файл <filename>falcot-data.desktop</filename>

en: 
    [Desktop Entry]
    Name=Internal Falcot Corp Documentation
    Comment=Starts a browser to read the documentation
    Exec=x-www-browser /usr/share/falcot-data/index.html
    Terminal=false
    Type=Application
    Categories=Documentation;
ru-RU: 
    [Desktop Entry]
    Name=Internal Falcot Corp Documentation
    Name[ru]=Внутренняя документация Falcot Corp
    Comment=Starts a browser to read the documentation
    Comment[ru]=Запускает браузер для чтения документации
    Exec=x-www-browser /usr/share/falcot-data/index.html
    Terminal=false
    Type=Application
    Categories=Documentation;

en: The updated <filename>debian/falcot-data.install</filename> looks like this:
ru-RU: Изменённый файл <filename>debian/falcot-data.install</filename> выглядит следующим образом:

en: Our source package is now ready. All that is left to do is to generate the binary package, with the same method we used previously for rebuilding packages: we run the <command>dpkg-buildpackage -us -uc</command> command from within the <filename>falcot-data-1.0</filename> directory.
ru-RU: Наш пакет исходного кода теперь готов. Все, что осталось сделать, это создать двоичный пакет тем же методом, который мы использовали ранее для пересборки пакетов: мы запускаем команду <command>dpkg-buildpackage -us -uc</command> в каталоге <filename>falcot-data-1.0</filename>.

en: Creating a Package Repository for APT
ru-RU: Создание репозитория пакетов для APT

en: <primary>package</primary><secondary>Debian</secondary><tertiary>archive of</tertiary>
ru-RU: <primary>пакет</primary><secondary>Debian</secondary><tertiary>архив</tertiary>

en: Falcot Corp gradually started maintaining a number of Debian packages either locally modified from existing packages or created from scratch to distribute internal data and programs.
ru-RU: Falcot Corp со временем начала сопровождение нескольких пакетов Debian, либо локально модифицированных из существующих пакетов, либо созданных с нуля с целью распространять внутренние данные и программы.

en: To make deployment easier, they want to integrate these packages in a package archive that can be directly used by APT. For obvious maintenance reasons, they wish to separate internal packages from locally-rebuilt packages. The goal is for the matching entries in a <filename>/etc/apt/sources.list.d/falcot.list</filename> file to be as follows:
ru-RU: Чтобы упростить процесс развёртывания, им необходимо интегрировать эти пакеты в хранилище, которое может быть использовано непосредственно с помощью APT. В силу очевидных причин они хотят отделить внутренние пакеты от пересобранных локально. Цель состоит в том, чтобы можно было привести записи в файле <filename>/etc/apt/sources.list.d/falcot.list</filename> к следующему виду:

en: The administrators therefore configure a virtual host on their internal HTTP server, with <filename>/srv/vhosts/packages/</filename> as the root of the associated web space. The management of the archive itself is delegated to the <command>mini-dinstall</command> command (in the similarly-named package). This tool keeps an eye on an <filename>incoming/</filename> directory (in our case, <filename>/srv/vhosts/packages/mini-dinstall/incoming/</filename>) and waits for new packages there; when a package is uploaded, it is installed into a Debian archive at <filename>/srv/vhosts/packages/</filename>. The <command>mini-dinstall</command> command reads the <filename>*.changes</filename> file created when the Debian package is generated. These files contain a list of all other files associated with the version of the package (<filename>*.deb</filename>, <filename>*.dsc</filename>, <filename>*.diff.gz</filename>/<filename>*.debian.tar.gz</filename>, <filename>*.orig.tar.gz</filename>, or their equivalents with other compression tools), and these allow <command>mini-dinstall</command> to know which files to install. <filename>*.changes</filename> files also contain the name of the target distribution (often <literal>unstable</literal>) mentioned in the latest <filename>debian/changelog</filename> entry, and <command>mini-dinstall</command> uses this information to decide where the package should be installed. This is why administrators must always change this field before building a package, and set it to <literal>internal</literal> or <literal>updates</literal>, depending on the target location. <command>mini-dinstall</command> then generates the files required by APT, such as <filename>Packages.gz</filename>.
ru-RU: Соответственно, администраторы настраивают на своем внутреннем HTTP-сервере виртуальный хост с корневым каталогом <filename>/srv/vhosts/packages/</filename>. Управление самим архивом осуществляется командой <command>mini-dinstall</command> (из одноимённого пакета). Этот инструмент следит за каталогом <filename>incoming/</filename> (в нашем случае это <filename>/srv/vhosts/ packages/mini-dinstall/incoming/</filename>) и ожидает появления пакетов в нём; когда пакет будет загружен, он установится в хранилище Debian по адресу <filename>/srv/vhosts/packages/</filename>. Команда <command>mini-dinstall</command> считывает файл <filename>*.changes</filename>, создающийся при сбоке пакета Debian. Эти файлы содержат список всех прочих файлов, относящихя к этой версии пакета (<filename>*.deb</filename>, <filename>*.dsc </filename>, <filename>*.diff.gz</filename>/<filename>*.debian.tar.gz</filename>, <filename>*.orig.tar.gz</filename> или их эквивалентов, сжатых другими инструментами), и из них <command>mini-dinstall</command> узнаёт, какие файлы устанавливать. Файлы <filename>*.changes</filename> также содержат название целевого дистрибутива (чаще <literal>unstable</literal>), указанного в последней записи в <filename>debian/changelog</filename>, и <command>mini-dinstall</command> использует эту информацию,чтобы решить, куда нужно установить пакеты. Поэтому администраторы перед сборкой пакета должны всегда изменять значение в этом поле на <literal>internal</literal> или <literal>updates</literal>, в зависимости от целевого расположения. Затем <command>mini-dinstall</command> создает файлы, необхдимые для APT, такие как <filename>Packages.gz</filename>.

en: If <command>mini-dinstall</command> seems too complex for your Debian archive needs, you can also use the <command>apt-ftparchive</command> command. This tool scans the contents of a directory and displays (on its standard output) a matching <filename>Packages</filename> file. In the Falcot Corp case, administrators could upload the packages directly into <filename>/srv/vhosts/packages/updates/</filename> or <filename>/srv/vhosts/packages/internal/</filename>, then run the following commands to create the <filename>Packages.gz</filename> files:
ru-RU: Если <command>mini-dinstall</command> кажется слишком сложным для вашего архива Debian, вы также можете использовать команду <command>apt-ftparchive</command>. Этот инструмент сканирует содержимое каталога и отображает (в своём стандартном выводе) соответствующий файл <filename>Packages</filename>. В случае Falcot Corp администраторы могут загрузить пакеты непосредственно в <filename>/srv/vhosts/packages/updates/</filename> или <filename>/srv/vhosts/packages/internal/</filename>, а затем запустить следующие команды для создания файлов <filename>Packages.gz</filename>:

en: The <command>apt-ftparchive sources</command> command allows creating <filename>Sources.gz</filename> files in a similar fashion.
ru-RU: Команда <command>apt-ftparchive sources</command> позволяет создать файлы <filename>Sources.gz</filename> аналогичным образом.

en: Configuring <command>mini-dinstall</command> requires setting up a <filename>~/.mini-dinstall.conf</filename> file; in the Falcot Corp case, the contents are as follows:
ru-RU: Настройка <command>mini-dinstall</command> сводится к созданию файла <filename>~/.mini-dinstall.conf</filename>; в случае Falcot Corp содержимое его будет следующим:

en: One decision worth noting is the generation of <filename>Release</filename> files for each archive. This can help manage package installation priorities using the <filename>/etc/apt/preferences</filename> configuration file (see <xref linkend="sect.apt.priorities" /> for details).
ru-RU: Решением, которое стоит отметить, является генерация файла <filename>Release</filename> для каждого хранилища. Это может помочь управлять приоритетами установки пакета с помощью конфигурационного файла <filename>/etc/apt/preferences</filename> (см. <xref linkend="sect.apt.priorities" />).

en: <emphasis>SECURITY</emphasis> <command>mini-dinstall</command> and permissions
ru-RU: <emphasis>БЕЗОПАСНОСТЬ</emphasis> <command>mini-dinstall</command> и права доступа

en: Since <command>mini-dinstall</command> has been designed to run as a regular user, there is no need to run it as root. The easiest way is to configure everything within the user account belonging to the administrator in charge of creating the Debian packages. Since only this administrator has the required permissions to put files in the <filename>incoming/</filename> directory, we can deduce that the administrator authenticated the origin of each package prior to deployment and <command>mini-dinstall</command> does not need to do it again. This explains the <literal>verify_sigs = 0</literal> parameter (which means that signatures need not be verified). However, if the contents of packages are sensitive, we can reverse the setting and elect to authenticate with a keyring containing the public keys of persons allowed to create packages (configured with the <literal>extra_keyrings</literal> parameter); <command>mini-dinstall</command> will then check the origin of each incoming package by analyzing the signature integrated to the <filename>*.changes</filename> file.
ru-RU: Поскольку <command>mini-dinstall</command> разработан с целью запуска от имени обычного пользователя, нет нужды запускать его от имени root. Самый простой способ — настроить всё в пределах учетной записи, принадлежащей администратору, отвечающему за создание пакетов Debian. Так как только этот администратор имеет необходимые полномочия, необходимые для размещения файлов в каталоге <filename>incoming/</filename> мы можем сделать вывод, что администратор проверил подлинное происхождение каждого пакета до развёртывания, и у <command>mini-dinstall</command> нет необходимости делать это снова. Это объясняет параметр <literal>verify_sigs = 0</literal> (который означает, что нет нужды проверять подписи). Однако, если содержимое пакетов уязвимо, мы можем изменить настройку и принять решение об аутентификации с помощью брелока, содержащего открытые ключи лиц, которым разрешено создавать пакеты (настроенного с помощью параметра <literal>extra_keyrings</literal>); в таком случае <command>mini-dinstall</command> проверит происхождение каждого входящего пакета, анализируя подпись, встроенную в файл <filename>*.changes</filename>.

en: Invoking <command>mini-dinstall</command> actually starts a daemon in the background. As long as this daemon runs, it will check for new packages in the <filename>incoming/</filename> directory every half-hour; when a new package arrives, it will be moved to the archive and the appropriate <filename>Packages.gz</filename> and <filename>Sources.gz</filename> files will be regenerated. If running a daemon is a problem, <command>mini-dinstall</command> can also be manually invoked in batch mode (with the <literal>-b</literal> option) every time a package is uploaded into the <filename>incoming/</filename> directory. Other possibilities provided by <command>mini-dinstall</command> are documented in its <citerefentry><refentrytitle>mini-dinstall</refentrytitle> <manvolnum>1</manvolnum></citerefentry> manual page.
ru-RU: Вызов <command>mini-dinstall</command> на самом деле запускает демон в фоне. Пока этот демон работает, он будет проверять наличие новых пакетов в каталоге <filename>incoming/</filename> каждые полчаса; когда прибывает новый пакет, он будет перемещён в архив, и файлы <filename>Packages.gz</filename> and <filename>Sources.gz</filename> создадутся заново. Если запуск демона проблематичен, <command>mini-dinstall</command> можно также вызывать вручную в пакетном режиме (с опцией <literal>-b</literal>) каждый раз, когда пакет загружается в каталог <filename>incoming/</filename>. Другие возможности, предоставляемые <command>mini-dinstall</command>, документированы на странице руководства <citerefentry><refentrytitle>mini-dinstall</refentrytitle> <manvolnum>1</manvolnum></citerefentry>.

en: <emphasis>EXTRA</emphasis> Generating a signed archive
ru-RU: <emphasis>ДОПОЛНИТЕЛЬНО</emphasis> Создание подписанного архива

en: The APT suite checks a chain of cryptographic signatures on the packages it handles before installing them, in order to ensure their authenticity (see <xref linkend="sect.package-authentication" />). Private APT archives can then be a problem, since the machines using them will keep displaying warnings about unsigned packages. A diligent administrator will therefore integrate private archives with the secure APT mechanism.
ru-RU: Комплект APT проверяет цепочку криптографических подписей пакетов, которые он обрабатывает перед их установкой, в целях проверки их подлинности (см. <xref linkend="sect.package-authentication" />). Частные архивы APT поэтому могут создать проблему, так как машины, использующие их, будут постоянно выводить предупреждения о наличии неподписанных пакетов. Поэтому прилежный администратор увязывает частные архивы с безопасным механизмом APT.

en: To help with this process, <command>mini-dinstall</command> includes a <literal>release_signscript</literal> configuration option that allows specifying a script to use for generating the signature. A good starting point is the <filename>sign-release.sh</filename> script provided by the <emphasis role="pkg">mini-dinstall</emphasis> package in <filename>/usr/share/doc/mini-dinstall/examples/</filename>; local changes may be relevant.
ru-RU: Для помощи в этом процессе в <command>mini-dinstall</command> есть опция конфигурации <literal>release_signscript</literal>, которая позволяет задать сценарий, используемый для генерации подписи. Хорошей отправной точкой является сценарий <filename>sign-release.sh</filename>, предоставляемый пакетом<emphasis role="pkg">mini-dinstall</emphasis> в каталоге <filename>/usr/share/doc/mini-dinstall/examples/</filename>; локальные изменения могут быть уместны.

en: Becoming a Package Maintainer
ru-RU: Как стать сопровождающим пакета

en: Learning to Make Packages
ru-RU: Учимся создавать пакеты

en: Rules
ru-RU: Правила

en: A Debian package must comply with the precise rules compiled in the Debian policy, and each package maintainer must know them. There is no requirement to know them by heart, but rather to know they exist and to refer to them whenever a choice presents a non-trivial alternative. Every Debian maintainer has made mistakes by not knowing about a rule, but this is not a huge problem as long as the error gets fixed when a user reports it as a bug report (which tends to happen fairly soon thanks to advanced users). The <literal>Standards-Version</literal> field in <filename>debian/control</filename> specifies the version of the Debian policy with which a package complies. Maintainers should comply to the latest version of the Debian policy. <ulink type="block" url="https://www.debian.org/doc/debian-policy/" />
ru-RU: Пакет Debian должен подчиняться чётким правилам, сведённым в политику Debian, и каждый сопровождающий пакета должен знать их. Не требуется вызубрить их наизусть, но нужно знать, что они существуют, и обращаться к ним всякий раз, сталкиваясь с нетривиальным выбором. Каждый сопровождающий Debian совершал ошибки, не зная о правиле, однако это не особо страшно, если ошибка исправлена после того, как пользователь отправил отчёт о ней (что, как правило, происходит довольно быстро благодаря продвинутым пользователям). Поле <literal>Standards-Version</literal> в <filename>debian/control</filename> указывает версию политики Debian, которой соответствует пакет. Сопровождающие должны обеспечивать соответствие последней версии политики Debian. <ulink type="block" url="https://www.debian.org/doc/debian-policy/" />

en: Procedures
ru-RU: Методика

en: Debian is not a simple collection of individual packages. Everyone's packaging work is part of a collective project; being a Debian developer involves knowing how the Debian project operates as a whole. Every developer will, sooner or later, interact with others. The Debian Developer's Reference (in the <emphasis role="pkg">developers-reference</emphasis> package) summarizes what every developer must know in order to interact as smoothly as possible with the various teams within the project, and to take the best possible advantages of the available resources. This document also enumerates a number of duties a developer is expected to fulfill. <ulink type="block" url="https://www.debian.org/doc/manuals/developers-reference/" />
ru-RU: Debian — это не просто набор отдельных пакетов. Работа каждого по пакетированию является частью коллективного проекта; быть разработчиком Debian — значит знать каким образом проект Debian работает как единое целое. Каждому разработчику рано или поздно придётся взаимодействовать с другими. В cправочнике разработчика Debian (в пакете <emphasis role="pkg">developers-reference</emphasis>) сведена информация, которую нужно знать каждому разработчику для успешного взаимодействия с различными командами в рамках проекта и наиболее эффективного использования имеющихся ресурсов. В этом документе также перечисляется ряд обязанностей разработчика, которые должны выполняться. <ulink type="block" url="https://www.debian.org/doc/manuals/developers-reference/" />

en: Tools
ru-RU: Инструменты

en: Many tools help package maintainers in their work. This section describes them quickly, but does not give the full details, since they all have comprehensive documentation of their own.
ru-RU: Множество инструментов помогает сопровождающим пакетов в их работе. В этом раздел они описываются вкратце, без подробностей, так как все они сопровождаются исчерпывающей документацией.

en: The <emphasis role="pkg">devscripts</emphasis> package contains many programs helping with a wide array of a Debian developer's job:
ru-RU: Пакет <emphasis role="pkg">devscripts</emphasis> содержит множество программ, оказывающих помощь в широком круге задач разработчика Debian:

en: <command>debuild</command> allows generating a package (with <command>dpkg-buildpackage</command>) and running <command>lintian</command> to check its compliance with the Debian policy afterwards.
ru-RU: <command>debuild</command> позволяет создавать пакет (с помощью <command>dpkg-buildpackage</command>) и после этого запускать <command>lintian</command> для проверки его соответствия с политикой Debian.

en: <command>debclean</command> cleans a source package after a binary package has been generated.
ru-RU: <command>debclean</command> очищает пакет исходных текстов после создания двоичного пакета.

en: <command>dch</command> allows quick and easy editing of a <filename>debian/changelog</filename> file in a source package.
ru-RU: <command>dch</command> позволяет быстро и легко редактировать файл <filename>debian/changelog</filename> из пакета исходного кода.

en: <command>uscan</command> checks whether a new version of a software has been released by the upstream author; this requires a <filename>debian/watch</filename> file with a description of the location of such releases.
ru-RU: <command>uscan</command> проверяет, была ли выпущена новая версия программного обеспечения основными авторами; для этого требуется наличие файла <filename>debian/watch</filename> с описанием размещения таких выпусков.

en: <command>debi</command> allows installing (with <command>dpkg -i</command>) the Debian package that was just generated without the need to type its full name and path.
ru-RU: <command>debi</command> позволяет устанавливать (с помощью <command>dpkg -i</command>) только что созданный пакет Debian без необходимости вводить его полное имя и путь.

en: In a similar fashion, <command>debc</command> allows scanning the contents of the recently-generated package (with <command>dpkg -c</command>), without needing to type its full name and path.
ru-RU: Аналогичным образом, <command>debc</command> позволяет сканировать содержимое недавно созданного пакета (с помощью <command>dpkg -c</command>) без необходимости вводить его полное имя и путь.

en: <command>debrelease</command> uploads a recently-generated package to a remote server, without needing to type the full name and path of the related <filename>.changes</filename> file.
ru-RU: <command>debrelease</command> загружает недавно созданный пакет на удалённый сервер без необходимости ввода полного имени и пути соответствующего файла <filename>.changes</filename>.

en: <command>debsign</command> signs the <filename>*.dsc</filename> and <filename>*.changes</filename> files.
ru-RU: <command>debsign</command> подписывает файлы <filename>*.dsc</filename> и <filename>*.changes</filename>.

en: <command>uupdate</command> automates the creation of a new revision of a package when a new upstream version has been released.
ru-RU: <command>uupdate</command> автоматизирует создание новой редакции пакета, как только новая версия будет выпущена разработчиками программы.

en: <emphasis role="pkg">debhelper</emphasis> and <emphasis role="pkg">dh-make</emphasis>
ru-RU: <emphasis role="pkg">debhelper</emphasis> и <emphasis role="pkg">dh-make</emphasis>

en: The <command>dh_make</command> script (in the <emphasis>dh-make</emphasis> package) creates files required for generating a Debian package in a directory initially containing the sources for a piece of software. As can be guessed from the name of the program, the generated files use debhelper by default.
ru-RU: Сценарий <command>dh_make</command> (из пакета <emphasis>dh-make</emphasis>) создает файлы, необходимые для создания пакета Debian в каталоге, изначально содержащем исходный код программы. Как можно догадаться из названия программы, сформированные файлы по умолчанию используют debhelper.

en: This tool is one of the most important: it is the Debian package checker. It is based on a large array of tests created from the Debian policy, and detects quickly and automatically many errors that can then be fixed before packages are released.
ru-RU: Этот инструмент является одним из самых важных: он осуществляет проверку пакета Debian. Он включает большое количество тестов, созданных на основе политики Debian, и автоматически выявляет огромное число возможных ошибок, которые потом можно исправить до выпуска пакетов.

en: This tool is only a helper, and it sometimes gets it wrong (for instance, since the Debian policy changes over time, <command>lintian</command> is sometimes outdated). It is also not exhaustive: not getting any Lintian error should not be interpreted as a proof that the package is perfect; at most, it avoids the most common errors.
ru-RU: Этот инструмент является лишь вспомогательным, и иногда ошибается (например из-за того, что политики Debian со временем меняются, <command>lintian</command> иногда устаревает). Это тоже еще не все: отсутствие каких-либо ошибок, получаемых от Lintian, не следует интерпретировать как доказательство идеальности пакета; большее, на что он способен, это помочь избежать наиболее распространенных ошибок.

en: This is another important tool: it automates the installation, upgrade, removal and purge of a package (in an isolated environment), and checks that none of these operations leads to an error. It can help in detecting missing dependencies, and it also detects when files are incorrectly left over after the package got purged.
ru-RU: Это другой важный инструмент: он автоматизирует установку, обновление, удаление и полное удаление пакета (в изолированном окружении) и проверяет, что ни одна из этих операций не ведёт к ошибке. Он может помочь в обнаружении недостающих зависимостей, а также определяет, когда файлы по ошибке остаются в системе после полного удаления пакета.

en: <command>reprotest</command> builds the same source code twice in different environments, and then checks the binaries produced by each build for differences. If any are found, then <command>diffoscope</command> (if unavailable, <command>diff</command>) is used to display them in detail for later analysis.
ru-RU: <command>reprotest</command> собирает один и тот же исходный код дважды в разных окружениях, после чего проверяет, что двоичные файлы, созданные каждой сборкой, на отличия. Если таковые обнаруживаются, <command>diffoscope</command> (или, при её отсутствии, <command>diff</command>) используется, чтобы показать их для дальнейшего анализа.

en: <command>dupload</command> and <command>dput</command>
ru-RU: <command>dupload</command> и <command>dput</command>

en: Acceptance Process
ru-RU: Процесс принятия

en: Becoming a “Debian developer” is not a simple administrative matter. The process comprises several steps, and is as much an initiation as it is a selection process. In any case, it is formalized and well-documented, so anyone can track their progression on the website dedicated to the new member process. <ulink type="block" url="https://nm.debian.org/" />
ru-RU: Принятие в ряды разработчиков Debian — не простой административный вопрос. Процесс состоит из нескольких этапов и является в не меньшей степени процессом посвящения, нежели отбора. Так или иначе, он формализован и хорошо документирован, поэтому любой может отслеживать их продвижение на веб-сайте, посвящённом новым участникам. <ulink type="block" url="http://nm.debian.org/" />

en: <emphasis>EXTRA</emphasis> Lightweight process for “Debian Maintainers”
ru-RU: <emphasis>ДОПОЛНИТЕЛЬНО</emphasis> Упрощённый процесс для «Сопровождающих Debian»

en: “Debian Maintainer” is another status that gives less privileges than “Debian developer” but whose associated process is quicker. With this status, the contributors can maintain their own packages only. A Debian developer only needs to perform a check on an initial upload, and issue a statement to the effect that they trust the prospective maintainer with the ability to maintain the package on their own.
ru-RU: Статус «Сопровождающий Debian» подразумевает меньше полномочий, чем «Разработчик Debian», процесс принятия происходит быстрее. Разработчику Debian необходимо лишь выполнить проверку при начальной загрузке и выступить с заявлением о том, что они доверяют потенциальному сопровождающему, и он способен сопровождать пакет самостоятельно.

en: Prerequisites
ru-RU: Предварительные требования

en: All candidates are expected to have at least a working knowledge of the English language. This is required at all levels: for the initial communications with the examiner, of course, but also later, since English is the preferred language for most of the documentation; also, package users will be communicating in English when reporting bugs, and they will expect replies in English.
ru-RU: Все кандидаты должны иметь, как минимум, практическое знание английского языка. Это необходимо на всех уровнях: само собой, для начальной связи с экзаменатором, и позднее, так как английский язык является предпочтительным языком для большей части документации; кроме того, пользователи пакетов будут общаться на английском языке при отправке сообщений об ошибках, и будут ожидать ответов на английском языке.

en: The other prerequisite deals with motivation. Becoming a Debian developer is a process that only makes sense if the candidate knows that their interest in Debian will last for many months. The acceptance process itself may last for several months, and Debian needs developers for the long haul; each package needs permanent maintenance, and not just an initial upload.
ru-RU: Другое требование касается мотивации. Пытаться стать разработчиком Debian имеет смысл, только если кандидат знает, что его интерес к Debian не угаснет в течение многих месяцев. Сам процесс принятия может длиться несколько месяцев, и Debian нуждается в разработчиках на долгосрочный период; каждый пакет требует постоянного обслуживания, а не только начальной загрузки.

en: Registration
ru-RU: Регистрация

en: The first (real) step consists in finding a sponsor or advocate; this means an official developer willing to state that they believe that accepting <emphasis>X</emphasis> would be a good thing for Debian. This usually implies that the candidate has already been active within the community, and that their work has been appreciated. If the candidate is shy and their work is not publicly touted, they can try to convince a Debian developer to advocate them by showing their work in a private way.
ru-RU: Первый (реальный) шаг состоит в том, чтобы найти спонсора или защитника; то есть официального разработчика, готового заявить о том, что он считает, что принятие <emphasis>X</emphasis> было бы полезно для Debian. Обычно это предполагает, что кандидат уже проявил активность в рамках сообщества, и что его работа была оценена. Если кандидат является застенчивым и его работа не афишировалась публично, он может попытаться убедить разработчика Debian выступить за него, продемонстрировав свою работу приватно.

en: <primary>key pair</primary>
ru-RU: <primary>пара ключей</primary>

en: At the same time, the candidate must generate a public/private RSA key pair with GnuPG, which should be signed by at least two official Debian developers. The signature authenticates the name on the key. Effectively, during a key signing party, each participant must show an official identification (usually an ID card or passport) together with their key identifiers. This step confirms the link between the human and the keys. This signature thus requires meeting in real life. If you have not yet met any Debian developers in a public free software conference, you can explicitly seek developers living nearby using the list on the following webpage as a starting point. <ulink type="block" url="https://wiki.debian.org/Keysigning" />
ru-RU: В то же время кандидат должен создать пару ключей RSA — открытый и секретный с помощью GnuPG, которая должна быть подписана не менее чем двумя официальными разработчиками Debian. Подпись удостоверяет имя владельца ключа. По сути, во время встречи для подписывания ключей каждый участник должен показать удостоверение личности (обычно ID-карту или паспорт) вместе с идентификационными данными своего ключа. Этот шаг подтверждает связь между человеком и ключами. Таким образом, для подписи необходима встреча в реальной жизни. Если вы ещё не встречали ни одного из разработчиков Debian на публичной конференции по свободному программному обеспечению, вы можете поискать разработчиков, живущих по соседству, используя список на следующей веб-странице в качестве отправной точки. <ulink type="block" url="https://wiki.debian.org/Keysigning" />

en: Once the registration on <literal>nm.debian.org</literal> has been validated by the advocate, an <emphasis>Application Manager</emphasis> is assigned to the candidate. The application manager will then drive the process through multiple pre-defined steps and checks.
ru-RU: После того, как регистрация на <literal>nm.debian.org</literal> была подтверждена защитником, к кандидату приставляется <emphasis>Менеджер заявлений</emphasis>. Он проведёт процесс через многочисленные требующиеся шаги и проверки.

en: The first verification is an identity check. If you already have a key signed by two Debian developers, this step is easy; otherwise, the application manager will try and guide you in your search for Debian developers close by to organize a meet-up and a key signing.
ru-RU: Первая проверка — идентификация личности. Если у вас уже есть ключ, подписанный двумя разработчиками Debian, этот шаг будет легким, в противном случае менеджер заявлений попытается помочь вам в поисках ближайших разработчиков Debian для организации встречи и подписания ключа.

en: Accepting the Principles
ru-RU: Соглашение с принципами

en: These administrative formalities are followed by philosophical considerations. The point is to make sure that the candidate understands and accepts the social contract and the principles behind Free Software. Joining Debian is only possible if one shares the values that unite the current developers, as expressed in the founding texts (and summarized in <xref linkend="the-debian-project" />).
ru-RU: Эти административные формальности проистекают из философских соображений. Смысл в том, чтобы убедиться, что кандидат понимает и принимает социальный контракт и принципы, лежащие в основе Свободного ПО. Присоединение к Debian возможно, только если он разделяет ценности, объединяющие текущих разработчиков, как изложено в основополагающих текстах (и обобщено в <xref linkend="the-debian-project" />).

en: In addition, each candidate wishing to join the Debian ranks is expected to know the workings of the project, and how to interact appropriately to solve the problems they will doubtless encounter as time passes. All of this information is generally documented in manuals targeting the new maintainers, and in the Debian developer's reference. An attentive reading of this document should be enough to answer the examiner's questions. If the answers are not satisfactory, the candidate will be informed. They will then have to read (again) the relevant documentation before trying again. In the cases where the existing documentation does not contain the appropriate answer for the question, the candidate can usually reach an answer with some practical experience within Debian, or potentially by discussing with other Debian developers. This mechanism ensures that candidates get involved somewhat in Debian before becoming a full part of it. It is a deliberate policy, by which candidates who eventually join the project are integrated as another piece of an infinitely extensible jigsaw puzzle.
ru-RU: Кроме того, каждый кандидат, желающий присоединиться к рейтингу Debian, должен быть осведомлен о деятельности проекта и о том, как надлежит взаимодействовать для решения проблем, с которыми он, несомненно, со временем столкнётся. Вся эта информация, как правило, описана в руководствах, ориентированных на новых сопровождающих, а также в справочнике разработчика Debian. Внимательного чтения этого документа должно быть достаточно для ответа на вопросы экзаменатора. Если ответы неудовлетворительны, кандидат будет проинформирован. В таком случае ему придется читать соответствующую документацию (ещё раз), прежде чем повторить попытку. В случаях, когда существующая документация не содержит подходящего ответа на вопрос, кандидат, как правило, может получить ответ при помощи некоторого практического опыта работы в Debian или, возможно, путем обсуждения с другими разработчиками Debian. Этот механизм гарантирует, что кандидаты тем или иным образом принимают участие в Debian до того, как стать его полноправным участником. Это продуманная политика,направленная на то, чтобы кандидаты, в конечном итоге присоединившиеся к проекту, встроились в него как очередной кусочек бесконечно расширяющегося пазла.

en: This step is usually known as the <emphasis>Philosophy &amp; Procedures</emphasis> (P&amp;P for short) in the lingo of the developers involved in the new member process.
ru-RU: Этот этап известен как <emphasis>Философия &amp; Процедуры</emphasis> (на английском языке — P&amp;P для краткости) на жаргоне разработчиков, участвующих в процессе принятия нового участника.

en: <primary><emphasis>Philosophy &amp; Procedures</emphasis></primary>
ru-RU: <primary><emphasis>Философия &amp; Процедуры</emphasis></primary>

en: Checking Skills
ru-RU: Проверка навыков

en: Each application to become an official Debian developer must be justified. Becoming a project member requires showing that this status is legitimate, and that it facilitates the candidate's job in helping Debian. The most common justification is that being granted Debian developer status eases maintenance of a Debian package, but it is not the only one. Some developers join the project to contribute to porting to a specific architecture, others want to improve documentation, and so on.
ru-RU: Каждое заявление на приём в официальные разработчики Debian должно быть обосновано. Чтобы стать участником проекта, нужно показать, что этот статус легитимен, и что он облегчает работу кандидата в оказании помощи Debian. Наиболее распространённое подтверждение легитимности статуса состоит в том, что статус разработчика Debian облегчает сопровождение пакета Debian, но оно не единственное. Некоторые разработчики присоединяются к проекту для того, чтобы внести свой вклад в перенос на определенную архитектуру, другие же хотят улучшить документацию и так далее.

en: This step represents the opportunity for the candidate to state what they intend to do within the Debian project and to show what they have already done towards that end. Debian is a pragmatic project and saying something is not enough, if the actions do not match what is announced. Generally, when the intended role within the project is related to package maintenance, a first version of the prospective package will have to be validated technically and uploaded to the Debian servers by a sponsor among the existing Debian developers.
ru-RU: На этом этапе кандидату предоставляется возможность заявить, что он намерен делать в рамках проекта Debian, и показать, что он уже сделал в этом направлении. Debian — прагматичный проект, и недостаточно просто сказать что-то, если слова расходятся с делом. В общем случае, когда желаемая роль в проекте связана с сопровождением пакета, первая версия будущего пакета должна пройти техническую проверку и быть загружена на серверы Debian спонсором из числа существующих разработчиков Debian.

en: <emphasis>COMMUNITY</emphasis> Sponsoring
ru-RU: <emphasis>СООБЩЕСТВО</emphasis> Спонсорство

en: <primary>sponsoring</primary>
ru-RU: <primary>спонсорство</primary>

en: Debian developers can “sponsor” packages prepared by someone else, meaning that they publish them in the official Debian repositories after having performed a careful review. This mechanism enables external persons, who have not yet gone through the new member process, to contribute occasionally to the project. At the same time, it ensures that all packages included in Debian have always been checked by an official member.
ru-RU: Разработчики Debian могут «спонсировать» пакеты, подготовленные кем-то ещё, то есть опубликовать их в официальных репозиториях Debian после тщательного разбора. Этот механизм позволяет внешним лицам, которые ещё не прошли через процесс принятия нового участника, время от времени вносить вклад в проект. В то же время это гарантирует, что все пакеты, включённые в Debian, были проверены официальным участником.

en: This step is known as the <emphasis>Tasks &amp; Skills</emphasis> step (T&amp;S for short) in the examiners' jargon.
ru-RU: Этот этап известен как <emphasis>Задачи &amp; Навыки</emphasis> на жаргоне экзаменаторов (на английском языке — T&amp;S для краткости).

en: <primary><emphasis>Tasks &amp; Skills</emphasis></primary>
ru-RU: <primary><emphasis>Задачи &amp; Навыки</emphasis></primary>

en: Final Approval
ru-RU: Окончательное утверждение

en: At the very last step, the whole process is reviewed by a DAM (<emphasis>Debian Account Manager</emphasis>). The DAM will review all the information about the candidate that the examiner collected, and makes the decision on whether or not to create an account on the Debian servers. In cases where extra information is required, the account creation may be delayed. Refusals are rather rare if the examiner does a good job of following the process, but they sometimes happen. They are never permanent, and the candidate is free to try again at a later time.
ru-RU: На самом последнем этапе весь процесс рассматривается DAM (<emphasis>Debian Account Manager</emphasis> — менеджером учётных записей Debian). DAM рассматривает всю информацию о кандидате, собранную экзаменатором, и принимает решение, создавать ли учётную запись на серверах Debian. В случаях, когда необходима дополнительная информация, создание учётной записи может быть отложено. Отказы весьма редки, если экзаменатор добросовестно соблюдает процесс, но иногда они случаются. Они никогда не бывают постоянными, и кандидат волен попробовать ещё раз позднее.

en: The DAM's decision is authoritative and (almost) without appeal, which explains why the people in that seat have often been criticized in the past.
ru-RU: Решение менеджера учётных записей является окончательным, (почти) без права на обжалование, что объясняет, почему люди находящиеся на этой позиции, часто критиковались в прошлом.
