Глава 5. Управление пакетами

Содержание

5.1. Новые пакеты
5.2. Запись изменений в пакете
5.3. Тестирование пакета
5.4. Схема пакета с исходным кодом
5.5. Выбор выпуска
5.5.1. Специальный случай: загрузка в стабильный и предыдущий стабильный выпуски
5.5.2. Специальный случай: загрузка в testing/testing-proposed-updates
5.6. Загрузка пакета
5.6.1. Загрузка на ftp-master
5.6.2. Задержанные загрузки
5.6.3. Загрузки безопасности
5.6.4. Другие очереди загрузки
5.6.5. Notifications
5.7. Определение раздела для пакета, подраздела и приоритета
5.8. Работа с ошибками
5.8.1. Мониторинг ошибок
5.8.2. Ответ на ошибки
5.8.3. Работа с ошибками
5.8.4. Когда ошибки исправляются путём новых загрузок
5.8.5. Работа с ошибками, связанными с безопасностью
5.8.5.1. Система отслеживания безопасности
5.8.5.2. Конфиденциальность
5.8.5.3. Рекомендации по безопасности
5.8.5.4. Подготовка пакетов для решения проблем безопасности
5.8.5.5. Загрузка исправленного пакета
5.9. Перемещение, удаление, переименование, придание статуса осиротевшего, усыновление и повторное введение пакетов
5.9.1. Перемещение пакетов
5.9.2. Удаление пакетов
5.9.2.1. Удаление пакетов из каталога Incoming (каталога входящих пакетов)
5.9.3. Замена или переименование пакетов
5.9.4. Придание статуса осиротевшего пакета
5.9.5. Усыновление пакета
5.9.6. Повторное добавление пакетов
5.10. Работа на переносом и перенос пакетов
5.10.1. Будьте добры к тем, кто занимается переносом
5.10.2. Руководство для загрузок теми, кто занимается переносом
5.10.2.1. Повторная компиляция или только двоичные NMU
5.10.2.2. Когда следует делать NMU, если вы занимаетесь переносом
5.10.3. Инфраструктура переноса и автоматизация
5.10.3.1. Списки рассылки и веб-страницы
5.10.3.2. Инструменты переноса
5.10.3.3. wanna-build
5.10.4. Если ваш пакет не может быть перенесён
5.10.5. Отмечаем несвободные пакеты как собираемые автоматически (auto-buildable)
5.11. Загрузки не-сопровождающим (NMU)
5.11.1. Когда и как делать NMU
5.11.2. NMU и файл debian/changelog
5.11.3. Использование очереди DELAYED/
5.11.4. NMU с точки зрения сопровождающего
5.11.5. NMU исходного кода и двоичные NMU (binNMU)
5.11.6. NMU и загрузки командой контроля качества
5.11.7. NMU и командные загрузки
5.12. Package Salvaging
5.12.1. When a package is eligible for package salvaging
5.12.2. How to salvage a package
5.13. Совместное сопровождение
5.14. Тестируемый выпуск
5.14.1. Основы
5.14.2. Обновления из нестабильного выпуска
5.14.2.1. Устаревание
5.14.2.2. Удаление из тестируемого выпуска
5.14.2.3. Круговые зависимости
5.14.2.4. Влияние пакета в тестируемом выпуске
5.14.2.5. Подробности
5.14.3. Прямые обновления тестируемого выпуска
5.14.4. Часто задаваемые вопросы
5.14.4.1. Что такое критичные для выпуска ошибки, как производится их подсчёт?
5.14.4.2. Как установка какого-то пакета в тестируемый выпуск может сломать другие пакеты?

Данная глава содержит информацию, связанную с созданием, загрузкой, сопровождением и переносом пакетов.

Если вы хотите создать новый пакет для дистрибутива Debian, вам следует вначале проверить список требующих доработки и будущих пакетов (WNPP). Проверка списка WNPP гарантирует, что в настоящий момент никто не работает над созданием пакетов для данного ПО, и что не будет проделана повторная работа. Прочтите страницу WNPP для получения дополнительной информации.

Допустим, что более никто не работает над вашим будущим пакетом. Далее, вам следует отправить сообщение об ошибке (раздел 7.1, «Отправка отчётов об ошибках») в псевдопакете wnpp с объяснением вашего плана по созданию нового пакета, ваше сообщение должно в себя включать описание пакета, лицензию будущего пакета и текущий адрес, по которому этот пакет может быть загружен.

Тема сообщения об ошибке должна иметь вид ITP: foo -- краткое описание, подставьте имя нового пакета вместо foo. Важность сообщения об ошибке должна быть установлена в значение wishlist. Отправьте копию по адресу , используя заголовок X-Debbugs-CC (не используйте CC:, так как в этом случае в теме сообщения не будет указан номер ошибки). Если вы создаёте много новых пакетов (>10), то помните, что отправка в список рассылки большого количества отдельных сообщений будет слишком мешать другим, отправьте сообщение с обзором вашей работы в список рассылки debian-devel после заполнения всех сообщений об ошибках. Это позволит сообщить вам другим разработчикам о готовящихся пакетах и позволит вам проверить ваши описания и имена пакетов.

Добавьте запись вида Closes: #nnnnn в журнал изменений нового пакета для того, чтобы ваше сообщение об ошибке было автоматически закрыто сразу же как только пакет будет установлен в архиве (см. раздел 5.8.4, «Когда ошибки исправляются путём новых загрузок»).

Если вы считаете, что по поводу вашего пакета необходимо дать дополнительные объяснения администраторам очереди новых (NEW) пакетов, добавьте их в журнал изменений, отправьте по адресу ваш ответ на сообщение электронной почты, которое вы получите как сопровождающий после вашей загрузки пакета, либо ответьте на сообщение об отказе, если вы осуществляете загрузку повторно.

Закрывая сообщения об ошибках безопасности, добавляйте номера CVE, а также Closes: #nnnnn. Это помогает команде безопасности отслеживать уязвимости. Если загрузка осуществляется для того, чтобы исправить ошибку, и если идентификационный номер рекомендации по безопасности ещё не известен, советуем вам во время следующей загрузки изменить запись в журнале изменений и добавить номер рекомендации. Даже в этом случае добавляйте все доступные указатели на общую информацию из записи оригинального журнала изменений.

Имеется ряд причин, почему мы просим сопровождающих анонсировать их намерения, они приведены ниже:

  • Это помогает (потенциальному) сопровождающему получить советы опытных людей, участвующих в списке рассылки, и позволяет этим людям узнать, работает ли уже кто-нибудь над созданием пакета для данного ПО.

  • Это позволяет другим людям, которые думают о работе над созданием пакета, знать, что кто-то уже начал этим заниматься, и поэтому можно объединить усилия.

  • Это позволяет остальным сопровождающим знать о данном пакете больше, чем то, что содержится в одной строке описания и обычной записи из журнала изменений вида „Initial release“, которые публикуются в .

  • Это помогает людям, которые постоянно пользуются нестабильным выпуском (и являются теми, кто первый широко тестирует пакеты). Нам следует поощрять этих людей.

  • Анонсы дают сопровождающим и другим заинтересованным сторонам лучшее понимание того, что происходит и что является новым в Проекте.

Наиболее частые причины для отказа в добавлении нового пакета см. по адресу https://ftp-master.debian.org/REJECT-FAQ.html.

Изменения, которые вы произвели в пакете, должны быть записаны в файл debian/changelog. Эти изменения должны содержать точное описание того, что было изменено, почему это было изменено (в случае если имеются какие-либо сомнения), а также номера закрываемых сообщений об ошибках. Кроме того, в журнале должно быть указано, когда была завершена работа над пакетом. Этот файл будет установлен как /usr/share/doc/пакет/changelog.Debian.gz, либо как /usr/share/doc/пакет/changelog.gz в случае, если пакет является родным.

Файл debian/changelog соответствует определённой структуре, имеющей ряд различных полей. Одно из этих полей, выпуск, описывается в разделе 5.5, «Выбор выпуска». Дополнительная информация о структуре этого файла может быть найдена в Политике Debian, в разделе с названием debian/changelog.

Записи журнала изменений могут использоваться для автоматического закрытия сообщений об ошибках Debian, когда пакет устанавливается в архив. См. раздел 5.8.4, «Когда ошибки исправляются путём новых загрузок».

Обычная запись в журнале изменений какого-либо пакета, содержащего новую версию из основной ветки разработки ПО, выглядит следующим образом:

  * New upstream release.

Имеются специальные инструменты, которые помогают вам создавать записи журнала изменений и готовить файл changelog к выпуску — см. раздел A.6.1, «devscripts» и раздел A.6.5, «dpkg-dev-el».

Также см. раздел 6.3, «Лучшие практики для debian/changelog».

До того как вы загрузите ваш пакет, вам следует провести его простое тестирование. Как минимум вам следует попытаться выполнить следующие действия (вам будет нужна более старая версия того же пакета Debian):

Имеется два типа пакетов Debian с исходным кодом:

  • так называемые родные пакеты, для которых нет различия между оригинальным исходным кодом и заплатами Debian

  • (более частные) пакеты, для которых имеется оригинальный исходный файл с tarball-архивом и другой файл, содержащий изменения, внесённые Проектом Debian

У родных пакетов пакеты с исходным кодом включают в себя исходный файл контроля (.dsc) и исходный архив в виде tarball (.tar.{gz,bz2,xz}). Пакет с исходным кодом неродного пакета включает в себя исходный файл контроля, оригинальный исходный файл в виде tarball (.orig.tar.{gz,bz2,xz}) и специфичные изменения Debian (.diff.gz для формата пакета с исходным кодом “1.0” или .debian.tar.{gz,bz2,xz} для формата пакета с исходным кодом “3.0 (quilt)”).

Для пакетов в исходном формате “1.0” то, является пакет родным или нет, определялось командой dpkg-source во время сборки. Сегодня же рекомендуется явным образом указывать желаемый исходный формат, помещая строку “3.0 (quilt)”, либо “3.0 (native)” в файл debian/source/format. Остаток настоящего раздела посвящён исключительно неродным пакетам.

The first time a version is uploaded that corresponds to a particular upstream version, the original source tar file must be uploaded and included in the .changes file. Subsequently, this very same tar file should be used to build the new diffs and .dsc files, and will not need to be re-uploaded.

По умолчанию команды dpkg-genchanges и dpkg-buildpackage включат оригинальный исходный tar-файл тогда и только тогда, когда текущая запись в журнале изменений содержит версию из основной ветки разработки, которая отличается от предыдущей записи. Это поведение может быть изменено при помощи использования -sa, что позволяет всегда включать оригинальный исходный tar-файл, либо -sd, что позволяет всегда игнорировать его.

Если оригинальный исходный код не включён в загрузку, оригинальный tar-файлс исходным кодом, используемый dpkg-source при создании файла .dsc и diff для загрузки должен побайтно совпадать с тем файлом, который уже добавлен в архив.

Please notice that, in non-native packages, permissions on files that are not present in the *.orig.tar.{gz,bz2,xz} will not be preserved, as diff does not store file permissions in the patch. However, when using source format “3.0 (quilt)”, permissions of files inside the debian directory are preserved since they are stored in a tar archive.

Каждая загрузка должна содержать явное указание того, для какого выпуска предназначается данный пакет. Процесс сборки пакета извлекает эту информацию из первой строки файла debian/changelog и помещает её в поле Distribution файла .changes.

Обычно пакеты загружаются в нестабильный выпуск. Загрузки в нестабильный (unstable) или экспериментальный (experimental) выпуски должны использовать эти названия выпуска в записях журнала изменений; uploads for other supported suites should use the suite codenames, as they avoid any ambiguity.

Фактически, существуют и другие выпуски: кодовое-имя-security, прочтите раздел 5.8.5, «Работа с ошибками, связанными с безопасностью» для получения дополнительной информации.

Нельзя загрузить пакет в несколько выпусков одновременно.

Загрузка в stable означает, что пакет будет передан в очередь proposed-updates-new для проверки управляющими стабильного выпуска, и если пакеты будут одобрены, то они будут установлены в каталог stable-proposed-updates архива Debian. Отсюда, в свою очередь, пакеты будут перенесены в stable во время формирования следующей редакции выпуска.

To ensure that your upload will be accepted, you should discuss the changes with the stable release team before you upload. For that, file a bug against the release.debian.org pseudo-package using reportbug, including the patch you want to apply to the package version currently in stable. The patch should be a source debdiff (see Раздел A.2.2, «debdiff») against the current version in stable. The changelog entry should be against the stable distribution (e.g. `buster') and should be detailed, including Closes statements for bugs that are fixed by the upload.

Необходимо с особым вниманием относиться к загрузке пакета в стабильный выпуск. По сути, пакет следует загружать в стабильный выпуск исключительно в случае, если произошло что-либо из ниже следующего:

  • действительно критическая проблема функциональности

  • пакет больше нельзя установить

  • пакет отсутствует в выпущенной архитектуре

In the past, uploads to stable were used to address security problems as well. However, this practice is deprecated, as uploads used for Debian security advisories (DSAs) are automatically copied to the appropriate proposed-updates archive when the advisory is released. See Раздел 5.8.5, «Работа с ошибками, связанными с безопасностью» for detailed information on handling security problems. If the security team deems the problem to be too benign to be fixed through a DSA, the stable release managers are usually willing to include your fix nonetheless in a regular upload to stable.

Изменение в пакете чего-либо ещё, что не является действительно важным, крайне не рекомендуется, поскольку даже тривиальные исправления могут вызвать появление новых ошибок.

Пакеты, загружаемые в стабильный выпуск, должны быть скомпилированы на системах, работающих под управлением стабильного выпуска, чтобы их зависимости были ограничены библиотеками (а также другими пакетами), доступными в стабильном выпуске; например, пакет, загруженный в стабильный выпуск, будет отклонён в том случае, если она зависит от пакета с библиотекой, который доступен только в нестабильном выпуске. Крайне не рекомендуется производить изменения зависимостей других пакетов (путём создания путаницы с Provides или файлами shlibs), которые могут привести к тому, что эти другие пакеты нельзя будет установить.

Загрузки в предыдущие стабильные выпуски возможны до тех пор, пока эти выпуски не будут добавлены в архив. Те же правила применяются и к стабильным выпускам.

To upload a package, you should upload the files (including the signed changes and dsc file) with anonymous ftp to ftp.upload.debian.org in the directory /pub/UploadQueue/. To get the files processed there, they need to be signed with a key in the Debian Developers keyring or the Debian Maintainers keyring (see https://wiki.debian.org/DebianMaintainer).

Заметьте, что вам следует переслать файл changes самым последним. В противном случае ваша загрузка может быть отклонены потому, что ПО для сопровождения архива, осуществляющее грамматический разбор файла changes, посчитает, что не все файлы были загружены.

Для загрузки пакетов Вам могут пригодиться пакеты dupload или dput.Эти удобные программы помогают автоматизировать процесс загрузки пакетов в Debian.

Для удаления пакетов см. ftp://ftp.upload.debian.org/pub/UploadQueue/README и пакет dcut.

Иногда полезно загрузить пакет сразу же, но так, чтобы этот пакет поступил в архив лишь несколько дней спустя. Например, при подготовке загрузки тем, кто не является сопровождающим, вы возможно захотите дать сопровождающему несколько дней для того, чтобы тот как-то отреагировал.

Загрузка в каталог задержанных пакетов приводит к сохранению пакета в очереди отложенной загрузки. Когда указанное время ожидания истечёт, пакет будет перемещён в обычный каталог входящих пакетов для его обработки. Это производится путём автоматической загрузки на ftp.upload.debian.org в каталог загрузки DELAYED/X-day (X может быть в интервале от 0 до 15). 0-дней загружается несколько раз в день на ftp.upload.debian.org.

Работая с dput, вы можете использовать параметр --delayed ЗАДЕРЖКА, чтобы поместить пакет в одну из очередей.

В Европе имеется альтернативная очередь загрузки по адресу ftp://ftp.eu.upload.debian.org/pub/UploadQueue/. Она работает точно так же как и ftp.upload.debian.org, но для разработчиков из Европы она может быть более удобной из-за более быстрого доступа.

Кроме того, пакеты можно загружать через ssh на ssh.upload.debian.org; файлы должны быть помещены в /srv/upload.debian.org/UploadQueue. Эта очередь не поддерживает отложенные загрузки.

Сопровождающие архива Debian ответственны за обработку загрузок пакетов. По большей части загрузки обрабатываются автоматически и ежедневно при помощи специальных инструментов для сопровождения архива, dak process-upload. Говоря более конкретно, обновление существующих пакетов, предназначенные для нестабильного выпуска, обрабатываются автоматически. В других случаях (особенно это касается новых пакетов) помещение загруженного пакета в выпуск осуществляется вручную. Если загрузки обрабатываются вручную, изменение архива может потребовать некоторого времени. Пожалуйста, будьте терпеливы.

В любом случае вы получите уведомление по электронной почте о том, что пакет был добавлен в архив, в этом уведомлении также указаны сообщения об ошибках, которые будут закрыты благодаря данной загрузке. Внимательно изучите это уведомление, проверьте, все ли сообщения об ошибках, которые должны быть закрыты, в нём указаны.

Уведомление об установке также включает в себя информацию о том, в какой раздел был добавлен ваш пакет. Если имеет место несоответствие, то вы получите об этом отдельное сообщение. Читайте ниже.

Заметьте, что если вы загрузили пакет через очереди, служба очередей также отправит вам уведомление по электронной почте.

Also note that new uploads are announced on the IRC channel #debian-devel-changes. If your upload fails silently, it could be that your package is improperly signed, in which case you can find more explanations on ssh.upload.debian.org:/srv/upload.debian.org/queued/run/log.

Поля Section и Priority файла debian/control фактически не определяют то, куда в архиве будет помещён ваш пакет, также они не определяют приоритет. Для того, чтобы сохранить общую целостность архива, сопровождающие архива осуществляют контроль над данными полями. Значения в файле debian/control в действительности являются лишь подсказками.

Сопровождающие архива отслеживаю канонические разделы и приоритеты пакетов с помощью специального файла замещения. Если между файлом замещения и полями пакета, определёнными в файле debian/control, имеет место несоответствие, то вы получите сообщение о расхождении в момент, когда пакет будет установлен в архив. Вы можете либо исправить ваш файл debian/control во время следующей загрузки, либо вы можете захотеть изменить файл замещения.

Чтобы изменить раздел, в который был помещён пакет, вам для начала нужно убедиться, что файл debian/control в вашем пакете правилен. Далее, отправьте сообщение об ошибке в ftp.debian.org с запросом изменения раздела или приоритета для вашего пакета. Используйте тему сообщения на подобие override: ПАКЕТ1:раздел/приоритет, [...], ПАКЕТX:раздел/приоритет и добавьте обоснование данного изменения в теле сообщения об ошибке.

Дополнительную информацию о файлах замещения см. в dpkg-scanpackages(1) и https://www.debian.org/Bugs/Developer#maintincorrect.

Заметьте, что поле Section описывает и раздел, и подраздел, которые описываются в разделе 4.6.1, «Разделы». Если раздел имеет значение main (основной), то его указание должно быть опущено. Список разрешённых подразделов может быть найден в https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections.

Каждый разработчик должен быть способен работать с системой отслеживания ошибок Debian. Это предполагает знание того, как следует правильно отправлять сообщения об ошибках (см. раздел 7.1, «Отправка отчётов об ошибках»), как обновлять и упорядочивать их, а также то, как с ними работать и как их закрывать.

Возможности системы отслеживания ошибок описаны в документации по системе отслеживания ошибок для разработчиков. Она включает в себя описание того, как закрывать сообщения об ошибках, отправлять ответные сообщения, назначать важность и теги, отмечать ошибки как перенаправленные, а также многих других вопросов.

Такие операции как переназначение сообщений об ошибках другим пакетам, объединение отдельных сообщений об ошибках в одну проблему, а также повторное открытие ошибок, если они были закрыты прежде времени, осуществляются при помощи так называемого сервера управляющей почты. Все доступные на этом сервере команды описываются в документации по управляющему серверу системы отслеживания ошибок.

Если вы хотите быть хорошим сопровождающим, вам следует периодически проверять в системе отслеживания ошибок Debian (BTS) состояние ваших пакетов. Система отслеживания ошибок содержит все открытые сообщения об ошибках в ваших пакетах. Вы можете проверить их путём просмотра следующей страницы: https://bugs.debian.org/ваша-учётная-запись@debian.org.

Сопровождающие взаимодействуют с системой отслеживания ошибок через адреса электронной почты bugs.debian.org. Документация по доступным командам может быть найдена в https://www.debian.org/Bugs/, либо, если вы установили пакет doc-debian, вы можете посмотреть локальные файлы /usr/share/doc/debian/bug-*.

Некоторые разработчики находят полезным получение периодических отчётов об открытых ошибках. Вы можете добавить работу cron подобно следующей, если вы хотите получить еженедельные сообщения с обзором всех открытых сообщений об ошибках в ваших пакетах:

# запрашивает еженедельные отчёты об ошибках в моих пакетах
0 17 * * fri   echo "index maint address" | mail request@bugs.debian.org

Замените адрес вашим официальным адресом сопровождающего Debian.

When responding to bugs, make sure that any discussion you have about bugs is sent to the original submitter of the bug, the bug itself and (if you are not the maintainer of the package) the maintainer. Sending an email to will send the mail to the maintainer of the package and record your email with the bug log. If you don't remember the submitter email address, you can use to also contact the submitter of the bug. The latter address also records the email with the bug log, so if you are the maintainer of the package in question, it is enough to send the reply to . Otherwise you should include so that you also reach the package maintainer.

Если вы получили сообщение об ошибке, в котором упоминается FTBFS, то это означает Fails to build from source (не удалось собрать из исходного кода). Те, кто занимаются переносами, часто используют данный акроним.

Как только вы закончили работать с сообщением об ошибке (напр., исправили ошибку) отметьте его как завершённое (закройте его), отправив сообщение с объяснением по адресу . Если вы исправили ошибку путём изменения и загрузки пакета, вы можете автоматизировать закрытие сообщения об ошибке как это описано в разделе 5.8.4, «Когда ошибки исправляются путём новых загрузок».

Вам никогда не следует закрывать ошибки через отправку команды close для сервера ошибок по адресу . Если вы так сделаете, то изначальный автор сообщения об ошибке не получит какой-либо информации о том, почему сообщение об ошибке было закрыта.

Как сопровождающий пакетов вы часто будете находить ошибки в других пакетах, иногда вы будете получать сообщения об ошибках в ваших пакетах, которые в действительности касаются ошибок в других пакетах. Возможности системы отслеживания ошибок описываются в документации по системе отслеживания ошибок для разработчиков Debian. Такие операции как переназначение, объединение и отметка тегами сообщений об ошибках описываются в документации по управляющему серверу системы отслеживания ошибок. Данный раздел содержит некоторые рекомендации по управлению сообщениями об ошибках в ваших собственных пакетах, эти рекомендации основываются на коллективном опыте разработчиков Debian.

Отправка сообщений об ошибках по поводу проблем, которые вы найдёте в других пакетах, является одной из гражданских обязанностей сопровождающего, см. раздел 7.1, «Отправка отчётов об ошибках» для получения дополнительной информации. Тем не менее, работа с ошибками в ваших собственных пакетах ещё более важна.

Ниже приведена последовательность шагов, которой можно следовать при работе с сообщением об ошибке:

  1. Решите, соответствует присланный отчёт реальной ошибке или нет. Иногда пользователи всего лишь неправильно запускают программу, поскольку они не прочли документацию. Если вы это обнаружите, то просто закройте сообщение об ошибке, предоставив достаточное количество информации, которая позволит пользователю исправить свою проблему (вышлите ссылки на хорошую документацию и так далее). Если вы снова получите то же сообщение об ошибке, задайте себе вопрос, достаточно ли хороша документация, или может быть программа не может обнаружить случаи неправильного использования и выдать информативное сообщение об ошибке. Об этой проблеме следует сообщить автору основной ветки разработки.

    Если тот, кто отправил сообщение об ошибке, не согласен с вашим решением о закрытии сообщения об ошибке, то он может заново открывать его до тех пор, пока вы не придёте к согласию о том, что делать. Если вы не сможете найти общего решения, тогда вы можете отметить ошибку тегом wontfix, чтобы люди знали, что ошибка существует, но что она не будет исправлена. Если эта ситуация не приемлема, вы (или тот, кто отправил сообщение об ошибке) можете потребовать решение проблемы от технического комитета, переназначив сообщение об ошибке tech-ctte (вы можете использовать команду clone, если вы хотите, чтобы сообщение об ошибке осталось сообщением об ошибке в вашем пакете). До того, как сделать это, прочтите информацию о рекомендуемой процедуре.

  2. Если ошибка действительно имеет место, но она вызвана другим пакетом, просто переназначьте сообщение об ошибке тому пакету. Если вы не знаете, какому пакету следует переназначить сообщение об ошибке, вам следует попросить помощи в IRC или в . Пожалуйста, проинформируйте сопровождающего того пакета, которому вы переназначаете сообщение об ошибке, например, отправив копию сообщения для системы отслеживания ошибок, содержащего команды для переназначения, по адресу , объясните ему причины в своём сообщении. Заметьте, что простое переназначение не пересылается сопровождающим пакета, которому вы переназначаете сообщение об ошибке, поэтому они не будет знать об этом до тех пор, пока они не посмотрят сводную информацию об ошибках в своих пакетах.

    Если ошибка затрагивает работу вашего пакета, вы можете клонировать сообщение об ошибке и переназначить полученную копию тому пакету, который фактически вызывает нежелательное поведение в вашем пакете. В противном случае, ошибка не будет показываться в списке ошибок вашего пакета, что, вероятно, приведёт к тому, что пользователи будут снова и снова сообщать об одной и той же ошибке. Вам следует заблокировать "вашу" ошибку переназначенной, клонированной ошибкой, чтобы засвидетельствовать отношение между ними.

  3. Иногда вам также необходимо изменить важность ошибки так, чтобы она соответствовала вашему определению её важности. Люди обычно склонны преувеличивать важность ошибок для того, чтобы их ошибки были быстрее исправлены. Важность некоторых ошибок может понижена до wishlist, если запрашиваемое изменение является скорее косметическим.

  4. Если ошибка действительно имеет место, но об этой же проблеме было сообщено кем-то ещё, то два релевантных сообщения должны быть объединены в одно с помощью команды merge. В этом случае если ошибка будет исправлена, все те, кто сообщил о ней, будут уведомлены об этом. (Тем не менее, заметьте, что сообщения, отправленные одному из тех, кто сообщил об ошибке, не будут автоматически перенаправлены остальным пользователям, которые тоже сообщили об ошибке.) Подробности о технической стороне команды merge и родственной ей команды unmerge, см. в документации по управляющему серверу системы отслеживания ошибок.

  5. Пользователь, отправивший сообщение об ошибке, мог забыть предоставить какую-то информацию, в этом случае вам следует попросить их предоставить необходимую информацию. Вы можете использовать тег moreinfo, чтобы отметить сообщение об ошибке как требующее предоставления дополнительной информации. Более того, если вы не можете воспроизвести ошибку, вы можете пометить сообщение об ошибке тегом unreproducible. Это будет означать, что если кто-то может воспроизвести ошибку, то вы просите его предоставить вам дополнительную информацию о том, как воспроизвести эту ошибку. Через несколько месяцев, если эта дополнительная информация не была никем отправлена, сообщение об ошибке может быть закрыто.

  6. Если ошибка касается создания пакета, вам следует её исправить. Если вы не можете сами исправить её, то отметьте сообщение об ошибке тегом help. Кроме того, вы можете попросить о помощи в или . Если это проблема основной ветки разработки, вам следует переслать сообщение об ошибке автору основной ветки. Простой пересылки сообщения об ошибке не достаточно, вам следует проверять каждый выпуск основной ветки на предмет исправления этой ошибки. Если ошибка была исправлена, вам нужно просто закрыть сообщение об ошибке, в противном случае вам следует напомнить автору об ошибке. Если у вас имеются требуемые навыки, вы можете подготовить заплату, исправляющую ошибку и отправить её автору основной ветки. Убедитесь, что вы отправили заплату в систему отслеживания ошибок и пометили сообщение об ошибке тегом patch.

  7. Если вы исправили ошибку в своей локальной копии пакета, либо если исправление было загружено в репозиторий системы управления версиями, вы можете отметить сообщение об ошибке тегом pending, что будет означать, что ошибка исправлена, и что сообщение об ошибке будет закрыто при следующей загрузке (добавьте пункт closes: в ваш файл changelog). Это особенно полезно, когда над одним и тем же пакетом работает несколько разработчиков.

  8. Once a corrected package is available in the archive, the bug should be closed indicating the version in which it was fixed. This can be done automatically; read Раздел 5.8.4, «Когда ошибки исправляются путём новых загрузок».

Когда ошибки и проблемы в ваших пакетах будут исправлены, вам как сопровождающему следует закрыть сообщения об этих ошибках. Тем не менее, вам не следует закрывать сообщение об ошибке до того момента, как пакет, содержащий исправление ошибки, будет принят в архив Debian. Следовательно, как только вы получите уведомление о том, что загруженный вами пакет был установлен в архив, вы можете и должны закрыть сообщение об ошибке в системе отслеживания ошибок. Кроме того, сообщение об ошибке должно быть закрыто с указанием правильно версии, содержащей исправление ошибки.

Тем не менее, можно избежать необходимости ручного закрытия сообщений об ошибках после загрузки — просто перечислите ошибки в вашем файле debian/changelog, следуя определённым синтаксическим правилам, и ПО по сопровождению архива закроет соответствующие ошибки. Например:

acme-cannon (3.1415) unstable; urgency=low

  * Frobbed with options (closes: Bug#98339)
  * Added safety to prevent operator dismemberment, closes: bug#98765,
    bug#98713, #98714.
  * Added man page. Closes: #98725.

Технически говоря, следующее регулярное выражение Perl описывает то, как определяются журналы с закрытиями ошибок:

  /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig

We prefer the closes: #XXX syntax, as it is the most concise entry and the easiest to integrate with the text of the changelog. Unless specified differently by the -v-switch to dpkg-buildpackage, only the bugs closed in the most recent changelog entry are closed (basically, exactly the bugs mentioned in the changelog-part in the .changes file are closed).

Исторически загрузки определяются как загрузки теми, кто не является сопровождающим (NMU) отмечались тегом fixed, но не закрывались, но эта практика была прекращена с приходом отслеживания версий. То же самое справедливо и по отношению к тегу fixed-in-experimental.

Если вы неправильно введёте номер сообщения об ошибке или забудете указать этот номер в записи журнала изменений, не стесняйтесь исправить эту ошибку и её последствия. Чтобы заново открыть ошибочно закрытое сообщение об ошибке, отправьте команду reopen XXX на адрес системы управления системы отслеживания ошибок, . Чтобы закрыть любое сообщение об ошибках, указанная в котором ошибка была исправлена в вашей загрузке, перешлите файл .changes на адрес , вместо XXX укажите номер ошибки, также добавьте Version: YYY и пустую строку в качестве первых двух строк тела вашего сообщения, замените YYY на номер версии, в которой ошибка была исправлена.

Помните, что закрывать ошибки с помощью журнала изменений, как это описано выше, не является чем-то обязательным. Если вы просто хотите закрыть сообщения об ошибках, которые никак не касаются сделанной вами загрузки, закройте ошибку путём отправки вашего объяснения на адрес . Не закрывайте ошибки в записи журнала изменений какой-либо версии пакета, если изменения в этой версии пакета не имеют ничего общего с исправление этой ошибки.

Общую информацию о том, как писать журнал изменений, см. в разделе 6.3, «Лучшие практики для debian/changelog».

Из-за того, что ошибки, связанные с безопасностью, обладают скорее некоторой чувствительной природой, с ними следует работать очень внимательно. Команда безопасности Debian существует для того, чтобы координировать эту работу, следить за серьёзными проблемами безопасности, помогать сопровождающим в их работе с проблемами безопасности или исправлять эти проблемы, отправлять рекомендации по безопасности и сопровождать security.debian.org.

Если вам становится известно о какой-либо ошибке в пакете Debian, связанной с безопасностью, вне зависимости от того, являетесь вы сопровождающим этого пакета или нет, соберите информацию о проблеме, и сразу же свяжитесь с командой безопасности по электронной почте: . Если хотите, то можете зашифровать ваше сообщение ключом Debian Security Contact, см. https://www.debian.org/security/faq#contact. НЕ ЗАГРУЖАЙТЕ какие-либо пакеты в стабильный выпуск, не связавшись с командой безопасности. В качестве полезной информации понимается следующее:

  • Известно ли об этой ошибке широкой публике.

  • Какие версии пакета подвержены данной ошибке. Проверьте каждую версию, которая в настоящее время поддерживается выпуском Debian, а также тестируемый и нестабильный выпуски.

  • Суть исправления, если оно доступно (заплаты особенно полезны)

  • Любые исправленные пакеты, которые вы подготовили самостоятельно (отправьте только debdiff или только файлы .diff.gz и .dsc и прочтите раздел 5.8.5.4, «Подготовка пакетов для решения проблем безопасности»)

  • Любая помощь, которую вы можете предоставить в плане тестирования (уязвимость, тестирование регрессий и т. д.)

  • Любая информация, необходимая для рекомендации по безопасности (см. раздел 5.8.5.3, «Рекомендации по безопасности»)

Как сопровождающий пакетов вы ответственны за сопровождение своих пакетов даже в стабильном выпуске. Вы имеете лучшие возможности для оценки заплат и тестирования обновлённых пакетов, поэтому, пожалуйста, внимательно изучите приводимую ниже информацию о том, как подготовить пакеты для работы команды безопасности.

Команда безопасности сопровождает центральную базу данных, систему отслеживания безопасности Debian. Она содержит всю публично доступную информацию о том, что известно о проблемах безопасности: какие пакеты и версии подвержены проблемами, либо были исправлены, а также какие выпуски, стабильный, тестируемый и/или нестабильный, уязвимы. Конфиденциальная информация не добавляется в эту систему.

Вы можете производить поиск по конкретной проблеме или имени пакета. Посмотрите ваш пакет, чтобы узнать, какие проблемы всё ещё открыты. Если вы можете, предоставьте дополнительную информацию об этих проблемах, либо помогите решить их в вашем пакете. Все инструкции доступны на страницах системы отслеживания проблем.

В отличии от большей части другой деятельности, которая происходит в Debian, информация о проблемах безопасности иногда держится в секрете в течении некоторого времени. Это позволяет поставщикам ПО координировать раскрытие этой информации, чтобы минимизировать опасность для своих пользователей. Временное закрытие информации об уязвимости зависит от природы проблемы и соответствующего исправления, а также от того, находится ли уже информация об уязвимости в открытом доступе.

Разработчики могут узнать о проблемах безопасности из следующих источников:

  • они могут найти упоминание проблемы на публичном форуме (списке рассылки, веб-сайте и т. д.)

  • кто-то отправляет отчёт об ошибке

  • кто-то информирует через частную почту

В первых двух случаях информация публична, важно подготовить исправление ошибки как можно раньше. Тем не менее, в последнем случае информация об ошибке может не быть публичной. Тогда при работе с проблемой возможны несколько вариантов действий:

  • Если проблема безопасности не значительна, иногда нет необходимости скрывать информацию об этой проблеме, следует подготовить исправление и выпустить его.

  • Если проблема относится к серьёзным проблемам, желательно сообщить о ней другим поставщикам и скоординировать выпуск. Команда безопасности постоянно находится на связи с различными организациями и индивидами, и заботится о распространении информации и координации.

Если тот, кто сообщает о проблеме, просит не раскрывать её, то в любом случае такой запрос следует уважать, конечно, это не касается информирования команды безопасности с целью подготовки исправления для стабильного выпуска Debian. При отправка конфиденциальной информации команде безопасности, обязательно упомяните о полученной просьбе.

Заметьте, что если требуется сохранить тайну, то вы не можете загрузить исправление в нестабильный выпуск (или куда-либо ещё, например, в публичный репозиторий системы управления версиями). Запутывания информации о подробностях изменения не достаточно, поскольку сам код доступен общественности и может быть (и будет) просмотрен остальными людьми.

Однако имеются две причины выпускать информацию даже в том случае, если было запрошено этого не делать: проблема уже была известна в течении некоторого времени, либо проблема или эксплоит доступны публично.

Команда безопасности для общения по поводу чувствительных вопросов использует закодированную при помощи ключа PGP переписку. Подробности см. в ЧаВО команды безопасности.

Рекомендации по безопасности выпускаются только для текущего стабильного выпуска, а не для тестируемого или нестабильного выпусков. Рекомендации при их выпуске отправляются в список рассылки и размещаются на веб-странице о безопасности. Рекомендации по безопасности пишутся и публикуются командной безопасности. Тем не менее, они вовсе не против того, чтобы сопровождающий предоставил им какую-либо информацию или написал часть текста. В рекомендации по безопасности должна содержаться следующая информация:

  • Описание проблемы и её масштаба, включая следующее:

    • Тип проблемы (повышение привилегий, отказ в обслуживании и т. д.)

    • Какие привилегии могут быть получены и кем (если это имеет место)

    • Как эта уязвимость может использоваться

    • Может ли она использоваться удалённо, либо локально

    • Как проблема была исправлена

    Эта информация позволяет пользователям оценить угрозу их системам

  • Номера версий подверженных проблеме пакетов

  • Номера версий исправленных пакетов

  • Информация о том, где можно получить обновлённые пакеты (обычно из архива безопасности Debian)

  • Ссылки на рекомендации по безопасности основной ветки разработки, идентификационные номера CVE и любую другую информацию, полезную для перекрёстного указания уязвимости

Вы можете помочь команде безопасности, если предоставите им исправления пакетов, подходящие для рекомендации по безопасности для стабильного выпуска Debian.

When an update is made to the stable release, care must be taken to avoid changing system behavior or introducing new bugs. In order to do this, make as few changes as possible to fix the bug. Users and administrators rely on the exact behavior of a release once it is made, so any change that is made might break someone's system. This is especially true of libraries: make sure you never change the API (Application Program Interface) or ABI (Application Binary Interface), no matter how small the change.

Это означает, что переход на новую версию из основной ветки разработке не является хорошим решением. Вместо этого вам следует осуществить обратный перенос релевантных изменений в версию ПО, которая входит в стабильный выпуск Debian. Как правило, сопровождающие основной ветки разработки помогают сделать это, если это необходимо. Если же нет, то вам может помочь команда безопасности Debian.

В некоторых случаях обратный перенос исправления безопасности невозможен, например, когда должно быть изменено или переписано большое количество исходного кода. Если это имеет место, может потребоваться переход на новую версию основной ветки разработки. Тем не менее, это осуществляется только в крайних случаях, вам всегда следует заранее координировать такой переход с командой безопасности.

С этим де связан и другой важный совет: всегда тестируйте ваши изменения. Если у вас имеется эксплоит, попробуйте использовать его и выяснить, работает ли он на изначальном пакете и действительно ли он не работает на исправленном пакете. Также протестируйте другие, обычные действия, поскольку исправление безопасности может поломать даже кажущиеся несвязанными возможности.

Никогда НЕ добавляйте какие-либо изменения в ваш пакет, которые не связаны напрямую с исправлением уязвимости. Это лишь потребует вернуть изменения, это лишь зря потратит время разработчика. Если в вашем пакете имеются другие ошибки, которые вам хотелось бы исправить, подготовьте загрузку в proposed-updates обычным образом уже после того, как будет выпущена рекомендация по безопасности. Механизм обновления безопасности не служит для внесения в ваши пакеты таких изменений, которые в противном случае были бы отвернуты при их загрузке в стабильный выпуск, поэтому, пожалуйста, не пытайтесь этого делать.

Проверьте и протестируйте ваши изменения столько раз, сколько это возможно. Проверьте отличия от предыдущей версии (для этого очень полезны interdiff из пакета patchutils и debdiff из пакета devscripts, см. раздел A.2.2, «debdiff»).

Убедитесь, что вы проверили следующее:

  • Укажите верный выпуск в вашем файле debian/changelog: кодовое-имя-security (напр., buster-security). Не указывайте выпуск-proposed-updates или stable!

  • Загрузка должна иметь urgency=high.

  • Ваши записи в журнале изменений должны быть информативны и осмысленны. Другие пользователи будут полагаться не них при определении того, была исправлена определённая ошибка или нет. Добавляйте записи closes: о любых ошибках Debian. Всегда добавляйте внешнюю ссылку, желательно идентификатор CVE. Тем не менее, если идентификатор CVE ещё не был назначен, не ждите его, продолжайте процесс. Указать идентификатор можно позже.

  • Убедитесь, что номер версии верен. Он должен быть больше, чем номер версии текущего пакета, но меньше, чем версии пакетов в более поздних выпусках. Если вы сомневаетесь относительно версии, проверьте её с помощью dpkg --compare-versions. Будьте внимательны, не используйте повторно номер версии, который вы использовали для предыдущей загрузки, либо номер, конфликтующий с binNMU. Принято добавлять к номеру версии +debXu1 (где X представляет собой главный номер выпуска), напр., 1:2.4.3-4+deb10u1, для последующей загрузки версию, конечно же, следует увеличить на 1.

  • Если исходный код из основной ветки разработки не был ранее загружен на security.debian.org (во время предыдущего обновления безопасности), соберите свою загрузку с полным исходным кодом из основной ветки разработки (dpkg-buildpackage -sa). Если же ранее была произведена загрузка на security.debian.org, содержащая ту же самую версию из основной ветки разработки, вы можете осуществить загрузку без добавления исходного кода из основной ветки (dpkg-buildpackage -sd).

  • Убедитесь, что используется в точности тот же файл *.orig.tar.{gz,bz2,xz}, который использовался в обычном архиве, в противном случае переместить исправление безопасности в основной архив будет нельзя.

  • Соберите пакет в чистой системе, в которой установлен пакеты только из того выпуска, для которого вы собираете свой пакет. Если у вам нет такой системы, вы можете использовать машину debian.org (см. раздел 4.4, «Машины Debian»), либо настроить chroot (см. раздел A.4.3, «pbuilder» и раздел A.4.2, «debootstrap»).

Do NOT upload a package to the security upload queue (on *.security.upload.debian.org) without prior authorization from the security team. If the package does not exactly meet the team's requirements, it will cause many problems and delays in dealing with the unwanted upload.

Никогда НЕ загружайте ваше исправление в proposed-updates, не связавшись с командой безопасности. Пакеты из security.debian.org будут скопированы в каталог proposed-updates автоматически. Если какой-то пакет с тем же самым или более высоким номером версии уже установлен в архиве, обновление безопасности будет отклонено системой, управляющей архивом. В этом случае стабильный выпуск останется без обновления безопасности.

Once you have created and tested the new package and it has been approved by the security team, it needs to be uploaded so that it can be installed in the archives. For security uploads, the place to upload to is ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue/.

Как только будет принята ваша загрузка в очередь обновления безопасности, пакет будет автоматически собран для всех архитектур и сохранён для проверки командой безопасности.

Uploads that are waiting for acceptance or verification are only accessible by the security team. This is necessary since there might be fixes for security problems that cannot be disclosed yet.

Если член команды безопасности принимает пакет, этот пакет будет установлен в security.debian.org, а также предложен для соответствующего каталога выпуск-proposed-updates на ftp-master.debian.org.

Некоторые действия по управлению архивом в Debian не автоматизированы во время загрузки. Эти процедуры должны быть вручную выполнены сопровождающими. В данной главе содержатся советы о том, что следует делать в этих случаях.

Иногда для какого-то пакета раздел может быть изменён. Например, пакет из раздела non-free (раздел несвободных пакетов) может быть перелицензирован под GPL, в этом случае этот пакет следует переместить в `main' (основной раздел) или `contrib' (раздел ПО, зависящего от несвободного ПО).[3]

Если вам нужно изменить раздел у одного из ваших пакетов, измените управляющую информацию о пакете, затем заново загрузите ваш пакет (подробности см. в Руководстве по политике Debian). Вам следует чётко убедиться, что вы добавили .orig.tar.{gz,bz2,xz} в вашу загрузку (даже если вы не загружаете новую версию из основной ветки разработки), либо что этот файл не будет встречаться в новом разделе с остальной частью пакета. Если ваш новый раздел верен, пакет будет перемещён автоматически. Если же пакет не будет перемещён, тогда свяжитесь с управляющими ftp для того, чтобы понять, что же произошло.

Если, с другой стороны, вам необходимо изменить подраздел одного из ваших пакетов (напр., „devel“, „admin“), то это уже немного другая процедура. Исправьте подраздел в управляющем файле вашего пакета, затем заново загрузите пакет. Кроме того, вам следует обновить файл отклонений, это описано в разделе 5.7, «Определение раздела для пакета, подраздела и приоритета».

If for some reason you want to completely remove a package (say, if it is an old compatibility library which is no longer required), you need to file a bug against ftp.debian.org asking that the package be removed; as with all bugs, this bug should normally have normal severity. The bug title should be in the form RM: package [architecture list] -- reason, where package is the package to be removed and reason is a short summary of the reason for the removal request. [architecture list] is optional and only needed if the removal request only applies to some architectures, not all. Note that the reportbug will create a title conforming to these rules when you use it to report a bug against the ftp.debian.org pseudo-package.

If you want to remove a package you maintain, you should note this in the bug title by prepending ROM (Request Of Maintainer). There are several other standard acronyms used in the reasoning for a package removal; see https://ftp-master.debian.org/removals.html for a complete list. That page also provides a convenient overview of pending removal requests.

Note that removals can only be done for the unstable, experimental and stable distributions. Packages are not removed from testing directly. Rather, they will be removed automatically after the package has been removed from unstable and no package in testing depends on it. (Removals from testing are possible though by filing a removal bug report against the release.debian.org pseudo-package. See Раздел 5.14.2.2, «Удаление из тестируемого выпуска».)

Имеется одно исключение, при котором явный запрос об удалении не требуется: если двоичный пакет или пакет с исходным кодом более не может быть собран из исходного кода, в этом случае он будет удалён в полуавтоматическом режиме. Для двоичного пакета это означает, что у него более не имеется пакета с исходным кодом, который создаёт данный двоичный пакет; если двоичный пакет не создаётся на некоторых архитектурах, запрос об удалении этого пакета всё равно требуется. Для пакета с исходным кодом это означает, что все двоичные пакеты, на которые ссылается этот пакет, были приняты другим пакетом с исходным кодом.

В вашем запросе об удалении вам следует подробно описать причины, обосновывающие ваше требование. Это позволит избежать нежелательных удалений и отследить то, почему пакет был удалён. Например, вы можете указать имя пакета, которые заменяет удаляемый пакет.

Обычно просят удалить те пакеты, которые сопровождаются самим запрашивающим об удалении. Если вы хотите удалить другой пакет, вам следует получить на это разрешение от сопровождающего этого пакета. Если пакет должен быть признан осиротевшим, если он не имеет сопровождающего, то для начала вам следует обсудить запрос об удалении в . В случае если было принято решение об удалении пакета, вам следует переназначить сообщение об ошибке в пакете wnpp и изменить его заголовок на O: вместо того, чтобы отправлять новое сообщение об ошибке с запросом об удалении.

Дополнительная информация, связанная с этими вопросами, а также по теме удаления других пакетов может быть найдена по адресу https://wiki.debian.org/ftpmaster_Removals и https://qa.debian.org/howto-remove.html.

Если вы сомневаетесь в том, может ли быть удалён какой-либо пакет, обратитесь по адресу с этим вопросом. Кроме того, интерес представляет программа apt-cache из пакета apt. При запуске apt-cache showpkg пакет, эта программа отобразит подробную информацию о пакете, включая его обратные зависимости. Другими полезными программами являются apt-cache rdepends, apt-rdepends, build-rdeps (из пакета devscripts) и grep-dctrl. Удаление осиротевших пакетов обсуждается в .

После удаления пакета следует разобраться с его сообщениями об ошибках. Они должны быть либо переназначены другому пакету в случае, когда фактический код ПО развился в другой пакет (напр., libfoo12 был удалён из-за того, что libfoo13 его вытеснил), либо закрыты если это ПО более не является частью Debian. Закрывая сообщения об ошибках, не отмечайте их как исправленный в версиях пакета из предыдущих выпусков Debian, они должны быть отмечены как исправленные в <наиболее -свежей-версии-в-Debian>+rm.

Если сопровождающие основной ветки разработки решают изменить название своего ПО (либо если вы дали вашему пакету неверное имя), вам необходимо следовать процессу по переименованию пакета, который включает в себя два шага. На первом шаге измените файл debian/control так, чтобы в нём было отражено новое имя пакета, а также для того, чтобы устаревшее имя пакета было указано для замены, предоставления и в списке конфликтующих пакетов (см. Руководство по политике Debian). Заметьте, что вам следует добавлять отношение Provides только тогда, когда все пакет, зависящие от устаревшего пакета, продолжают работать после переименования. Когда вы загрузите пакет, и он будет перемещён в архив, отправьте сообщение об ошибке в псевдопакете ftp.debian.org с просьбой удалить пакет с устаревшим именем (см. раздел 5.9.2, «Удаление пакетов»). Не забудьте правильно переназначить сообщения об ошибке, чтобы они отсылали к новому имени пакета.

Вы можете допустить ошибку при создании вашего пакета, тогда вы захотите заменить свой пакет. Единственным способом сделать это является увеличение номера версии и загрузка новой версии пакет. Старая версия как обычно станет устаревшей. Заметьте, что это касается каждой части вашего пакета, включая и исходный код: если вы хотите заменить архив tarball с исходным кодом из основной ветки, вам придётся загрузить ваш пакет с другим номером версии. Проще всего заменить foo_1.00.orig.tar.gz на foo_1.00+0.orig.tar.gz, либо foo_1.00.orig.tar.bz2. Данное ограничение позволяет каждому файлу на ftp иметь уникальное имя, что помогает гарантировать согласованность в сети зеркал.

Если вы не можете более сопровождать пакет, вам нужно сообщить об этом остальным, и убедиться, что ваш пакет отмечен как осиротевший. Вам следует установить сопровождающего пакета в значение Debian QA Group <packages@qa.debian.org> и отправить сообщение об ошибке в псевдопакете wnpp. Заголовок сообщения об ошибке должен иметь вид O: пакет -- краткое описание, что показывает, что пакет осиротел. Важность сообщения об ошибке должна иметь значение normal; если пакет имеет стандартный приоритет или выше, важность сообщения об ошибке должна иметь значение important. Если вы считаете это необходимым, отправьте копию сообщения на адрес , добавив этот адрес в заголовок X-Debbugs-CC: вашего сообщения (не используйте CC:, так как тогда тема сообщения не будет содержать номер сообщения об ошибке).

Если вы хотите отдать пакет, но вы можете пока продолжать сопровождать его, то вам следует отправить сообщения об ошибке в псевдопакете wnpp, сообщение должно иметь заголовок вида RFA: пакет -- краткое описание. RFA означает Request For Adoption (запрос об усыновлении).

Дополнительная информация доступна на веб-страницах WNPP.

Список пакетов, которым требуются новые сопровождающие, доступен на странице Требующих доработки и будущих пакетов (WNPP). Если вы хотите заняться сопровождением какого-либо пакета из тех, что приведены в списке WNPP, обратитесь к вышеупомянутой странице для получения информации и сведений о процедуре.

It is not OK to simply take over a package without assent of the current maintainer — that would be package hijacking. You can, of course, contact the current maintainer and ask them for permission to take over the package.

However, when a package has been neglected by the maintainer, you might be able to take over package maintainership by following the package salvaging process as described in Раздел 5.12, «Package Salvaging». If you have reason to believe a maintainer is no longer active at all, see Раздел 7.4, «Работа с неактивными и/или недоступными сопровождающими».

Complaints about maintainers should be brought up on the developers' mailing list. If the discussion doesn't end with a positive conclusion, and the issue is of a technical nature, consider bringing it to the attention of the technical committee (see the technical committee web page for more information).

Если вы занялись работой над старым пакетом, вам вероятно захочется, чтобы в системе отслеживания ошибок в качестве официального сопровождающего этого пакета были указаны вы. Это будет сделано автоматически как только вы загрузите новую версию с обновлённым полем Maintainer, хотя на это может потребоваться несколько часов после выполнения загрузки. Если вы пока не собираетесь загружать новую версию, вы можете использовать информацию из раздела 4.10, «Система отслеживания пакетов Debian» для получения сообщений об ошибках. Тем не менее, убедитесь, что старый сопровождающий не против того факта, что он будет получать сообщения об ошибках в течении какого-то времени.

Пакеты часто удаляются из-за наличия в них критичных для выпуска ошибок, отсутствия сопровождающих, слишком малого числа пользователей или низкого качества. Хотя процесс повторного добавления пакета схож с первоначальной работой над пакетом, вы можете избежать некоторых ловушек, выполнив для начала небольшое историческое исследование.

Для начала вам следует проверить, почему пакет был удалён. Эта информация может быть найдена в сообщении об удалении в разделе новостей на странице системы отслеживания пакетов данного пакета, либо при просмотре журнала удалений. Сообщение об удалении в системе отслеживания ошибок содержит сведения о том, почему пакет был удалён, а также покажет вам то, над чем вам следует поработать для того, чтобы заново добавить пакет. В сообщении может содержаться сведения о том, что вместо повторного добавления пакета лучше всего переключиться на какое-то другое ПО.

Хорошо было бы связаться с предыдущими сопровождающими и выяснить, работают ли они над повторным добавлением пакета, заинтересованы ли они в совместном сопровождении пакета, заинтересованы ли они быть наставником пакета, если это необходимо.

Вам следует сделать всё, что требуется, до того как добавлять новые пакеты (раздел 5.1, «Новые пакеты»).

В качестве основы для своей работы вам следует взять самый последний из доступных и подходящих пакетов. Это может быть самая последняя версия из нестабильного выпуска, которая всё ещё доступна в снимке архива.

Система контроля версий, которая использовалась предыдущим сопровождающим, может содержать полезные изменения, поэтому проверка репозитория может оказаться хорошей идеей. Проверьте, содержит ли файл control в предыдущем пакете какие-либо заголовки со ссылками на систему контроля версий для данного пакета, и если да, то существует ли всё ещё этот репозиторий.

Удаление пакета из нестабильного выпуска (не из тестируемого, стабильного или предыдущего стабильного выпусков) приводит к закрытию всех сообщений об ошибках, которые связаны с удаляемым пакетом. Вам следует проверить все закрытые сообщения об ошибках (включая архивированные сообщения об ошибках), разархивировать и заново открыть любые закрытые сообщения об ошибках в версии, заканчивающейся на +rm, и которые всё ещё актуальны. Любые неактуальные сообщения об ошибках должны быть помечены как исправленные в той версии, в которой они были исправлены, если это, конечно, известно.

Package removals from unstable also trigger marking the package as removed in the security tracker. Debian members should mark removed issues as unfixed in the security tracker repository and all others should contact the security team to report reintroduced packages.

Debian поддерживает всё увеличивающееся число архитектур. Даже если вы не занимаетесь переносом и используете только одну архитектуру, вы как сопровождающий обязаны знать о проблемах, связанных с переносимостью. Следовательно, даже если вы не занимаетесь переносом, вам следует прочесть большую часть данной главы.

Porting is the act of building Debian packages for architectures that are different from the original architecture of the package maintainer's binary package. It is a unique and essential activity. In fact, porters do most of the actual compiling of Debian packages. For instance, when a maintainer uploads a (portable) source package with binaries for the i386 architecture, it will be built for each of the other architectures, amounting to 10 more builds.

У тех, кто занимается переносом, трудная и необычная задача, поскольку им необходимо работать с большим объёмом пакетов. В идеале каждый пакет с исходным кодом должен собираться прямо из коробки. К сожалению, зачастую это не так. Данный раздел содержит список „ошибочек“, которые часть совершают сопровождающие Debian — общих проблем, которые ставят в тупик тех, кто занимается переносом, и делают их работу неоправданно сложной.

The first and most important thing is to respond quickly to bugs or issues raised by porters. Please treat porters with courtesy, as if they were in fact co-maintainers of your package (which, in a way, they are). Please be tolerant of succinct or even unclear bug reports; do your best to hunt down whatever the problem is.

По большей части, почти все проблемы, на которые обращают внимание те, кто занимает переносом, вызваны ошибками, допущенными при создании пакетов, в пакетах с исходным кодом. Ниже приведён список того, что вам следует проверить или о чём нужно всегда помнить.

  1. Make sure that your Build-Depends and Build-Depends-Indep settings in debian/control are set properly. The best way to validate this is to use the debootstrap package to create an unstable chroot environment (see Раздел A.4.2, «debootstrap»). Within that chrooted environment, install the build-essential package and any package dependencies mentioned in Build-Depends and/or Build-Depends-Indep. Finally, try building your package within that chrooted environment. These steps can be automated by the use of the pbuilder program, which is provided by the package of the same name (see Раздел A.4.3, «pbuilder»).

    Если вы не можете правильно настроить chroot, вам может помочь dpkg-depcheck (см. раздел A.6.6, «dpkg-depcheck»).

    Инструкции по настройке сборочных зависимостей см. в Руководстве по политике Debian.

  2. Не указывайте в качестве архитектуры отличное от all ли any значение, если только вы действительно не имеете это в виду. В большинстве случаев сопровождающие не следуют инструкциям Руководства по политике Debian. Установка архитектуры в значение только какой-то одной архитектуры (такой как i386 или amd64) обычно оказывается неправильным.

  3. Убедитесь, что ваш пакет с исходным кодом корректен. Выполните dpkg-source -x пакет.dsc для того, чтобы убедиться, что ваш пакет с исходным кодом распаковывается правильно. Далее, попытайтесь собрать ваш пакет с нуля с помощью dpkg-buildpackage.

  4. Убедитесь, что в вашем пакете с исходным кодом нет файлов debian/files или debian/substvars. Они должны быть удалены при помощи цели clean из debian/rules.

  5. Make sure you don't rely on locally installed or hacked configurations or programs. For instance, you should never be calling programs in /usr/local/bin or the like. Try not to rely on programs being set up in a special way. Try building your package on another machine, even if it's the same architecture.

  6. Не используйте при сборке пакета какие-либо уже установленные пакеты (это более конкретный вариант приведённого выше случая). Конечно, бывают и исключения для этого правила, но помните, что любой подобный случай требует ручного вмешательства и не может быть выполнен автоматическими сборщиками пакетов.

  7. Если это возможно, не используйте компилятор какой-то конкретной версии. Если это невозможно, то убедитесь, что ваши сборочные зависимости отражают это ограничение, хотя вы, вероятно, просите о чём-то проблематичном, поскольку разные архитектуры иногда основываются на разных компиляторах.

  8. Убедитесь, что ваш файл debian/rules содержит отдельные цели binary-arch и binary-indep, как то требуется в Руководстве по политике Debian. Убедитесь, что обе цели работают независимо друг от друга, то есть, что вы можете вызвать одну цель, не вызывая до этого другой. Для проверки этого, попытайтесь запустить dpkg-buildpackage -B.

Если пакет собирается из коробки для той архитектуры, на которую он должен быть перенесён, то вам повезло и ваша работа довольно проста. Данный раздел касается этого случая; в разделе описывается то, как собирать и загружать ваш двоичный пакет так, чтобы он был правильно установлен в архив. Если вам требуется внести изменения в пакет для того, чтобы он мог быть скомпилирован для других архитектур, вам будет нужно выполнить NMU пакета с исходным кодом, поэтому обратитесь к разделу 5.11.1, «Когда и как делать NMU».

При загрузке тем, кто занимается переносом, изменения исходного кода не вносятся. Вам не нужно трогать какие-либо файлы в пакете с исходным кодом. Это предполагает и файл debian/changelog.

Можно вызвать dpkg-buildpackage как dpkg-buildpackage -B -mporter-email. Конечно, установите ваш адрес электронной почты в качестве значения поля porter-email. При использовании цели binary-arch в debian/rules будет выполнена сборка двоичных пакетов только для зависящих от архитектуры частей пакета.

Если вы работаете на машине Debian для того, чтобы заниматься переносом, и вам локально требуется подписать вашу загрузку для того, чтобы она была принята в архив, вы можете запустить debsign, указав ваш файл .changes в целях удобства, файл будет подписан, либо вы можете использовать удалённый режим подписывания командой dpkg-sig.

Иногда первоначальная загрузка, связанная с переносом, проблематична из-за того, что окружение, в котором был собран пакет, не было достаточно хорошо (устаревшая или не используемая более библиотека, плохой компилятор и т. д.). Тогда вам может потребоваться заново скомпилировать пакет в обновлённом окружении. Тем не менее, в этом случае вам придётся увеличить номер версии пакета, чтобы старый плохой пакет был заменён на новый в архиве Debian (dak отказывается устанавливать новые пакеты, если номер их версии не больше уже доступных пакетов).

Вам следует убедиться, что ваша двоичная NMU не приведёт к тому, что пакет перестанет устанавливаться. Это может произойти в случае, если пакет с исходным кодом порождает зависящие и независящие от архитектуры пакеты, взаимные зависимости которые созданы подстановкой переменной dpkg $(Source-Version).

Несмотря на необходимое изменение журнала изменений, это называется двоичной NMU — в этом случае нет необходимости делать пакеты других архитектур устаревшими и заново их компилировать.

Для такой повторной компиляции требуется специальное „магическое“ назначение версий, так чтобы инструменты для сопровождения архива распознали, что хотя даже и имеется новая Debian-версия, соответствующего обновления исходного кода не было. Если вы сделаете это неправильно, сопровождающие архива отклонят вашу загрузку (из-за отсутствия соответствующего исходного кода).

„Магия“ для NMU повторной компиляции включается путём использования суффикса в номере версии пакет, имеющего следующий вид: bномер. Например, если последняя версия пакета, которую вы заново компилируете, была версией 2.9-3, ваша двоичная NMU должна иметь версию 2.9-3+b1. Если последней версией была 3.4+b1 (т. е., родной пакет, для которого в предыдущий раз уже была выполнена NMU с повторной компиляцией), ваша двоичная NMU должна иметь номер версии 3.4+b2.[4]

Подобно первоначальной загрузке, связанной с переносом, правильный вызов dpkg-buildpackage имеет вид dpkg-buildpackage -B, что означает, что будут собраны только зависящие от архитектуры части пакета.

Те, кто занимаются переносом и выполняют NMU исходного кода, следуют советам из раздела 5.11, «Загрузки не-сопровождающим (NMU)», как и те, кто переносом не занимается. Тем не менее, ожидается, что цикл ожидания для NMU исходного кода, выполненной тем, кто занимается переносом, меньше, чем для того, кто переносом не занимается, поскольку те, кто занимается переносом, должны охватить большое количество пакетов. Опять же, ситуация зависит от того, в какой выпуск они хотят осуществить загрузку. Также важно то, является ли данная архитектура кандидатом на включение в следующий стабильный выпуск; управляющие выпуском решают и сообщают о том, какие архитектуры являются такими кандидатами.

Если вы не занимаетесь переносом и выполняете NMU для нестабильного выпуска, вам следует придерживаться приведённых выше советов по переносу, но с двумя изменениями. Во-первых, период ожидания принятия — время между тем, когда было сообщено об ошибке в систему отслеживания ошибок, и тем, когда для NMU наступает подходящее время — равен семи дням для тех, кто занимается переносом, и работает над нестабильным выпуском. Этот период может быть уменьшен по усмотрению тех, кто занимается переносом, в случае, если проблема является критической и представляет собой серьёзную трудность для процесса переноса пакета. (Помните, это не является Политикой, это лишь негласно принято в сообществе.) Для выполнения загрузки в стабильный или тестируемый выпуски свяжитесь с соответствующей выпускающей командой.

Во-вторых, те, кто занимается переносом и выполняют NMU исходного кода, должны убедиться, что сообщение об ошибке, отправленное в систему отслеживания ошибок, имеет важность serious или выше. Это гарантирует, что отдельный пакет с исходным кодом может использоваться для компиляции пакета для каждой поддерживаемой Debian на момент выпуска архитектуры. Важно, что у нас имеется одна версия двоичного пакета и пакета с исходным кодом для всех архитектур для того, чтобы соответствовать множеству лицензий.

Те, кто занимаются переносом, должны попытаться избежать заплат, которые просто обходят ошибки в текущей версии окружения компиляции, ядра или libc. Иногда такие клуджи не могут помочь. Если вам нужно обойти ошибки компилятора или чего-то подобного, убедитесь, что вы выполнили корректно #ifdef для своей работы; также, документируйте ваши клуджи, чтобы люди знали, как удалить их когда внешние проблемы будут исправлены.

У тех, кто занимается переносом, также имеется неофициальное место, куда они могут поместить результаты своей работы во время периода ожидания. Это помогает остальным, кто занимается переносом, использовать вашу работу даже во время периода ожидания. Конечно, такие места не являются официальными и не имеют какого-либо специального статуса, поэтому будьте внимательны.

Имеется специальная инфраструктура и некоторые инструменты, необходимые для автоматизации переноса пакетов. Данный раздел сдержит краткий обзор автоматизации и переноса с помощью данных инструментов; дополнительную информацию см. в документации пакетов или по другим ссылкам.

Веб-страницы, содержащие информацию о статусе каждого переноса, можно найти по адресу: https://www.debian.org/ports/.

У каждого переноса Debian имеется свой список рассылки. Список списков рассылки различных проектов по переносу может быть найден по адресу: https://lists.debian.org/ports.html. Эти списки рассылки используются для координации работы и связи пользователей с теми, кто работает над переносом.

The wanna-build system is used as a distributed, client-server build distribution system. It is usually used in conjunction with build daemons running the buildd program. Build daemons are ``slave'' hosts, which contact the central wanna-build system to receive a list of packages that need to be built.

wanna-build is not yet available as a package; however, all Debian porting efforts are using it for automated package building. The tool used to do the actual package builds, sbuild, is available as a package; see its description in Раздел A.4.4, «sbuild». Please note that the packaged version is not the same as the one used on build daemons, but it is close enough to reproduce problems.

Most of the data produced by wanna-build that is generally useful to porters is available on the web at https://buildd.debian.org/. This data includes nightly updated statistics, queueing information and logs for build attempts.

Мы очень гордимся этой системой, поскольку у неё так много возможных пользователей. Независимые от разработки группы могут использовать данную систему для подготовки различных вариантов Debian, которые иногда могут быть интересы и более широкому кругу пользователей (например, вариант Debian, собранный с поддержкой проверки связывания средствами gcc). Кроме того, она позволяет довольно быстро заново собрать целый выпуск Debian.

Связаться с командой wanna-build, ответственной за службы buildd, можно по адресу: debian-wb-team@lists.debian.org. Для того, чтобы определить, с кем (команда wanna-build, команда выпуска) и как (почта, система отслеживания ошибок) следует связаться в конкретном случае, см. https://lists.debian.org/debian-project/2009/03/msg00096.html.

При запросе binNMU или возвратов (повторов после неудачной сборки) используйте описанный в https://release.debian.org/wanna-build.txt формат.

Некоторые пакеты всё равно имеют проблемы со сборкой и/или с работой на некоторых поддерживаемых Debian архитектурах, они вообще не могут быть перенесены, либо для их переноса требуется слишком много времени. Примером этого является пакет, который конкретно связан с SVGA (доступен только для i386 и amd64), либо использует другие специфические возможности оборудования, которые совсем не поддерживаются на всех архитектурах.

Для того, чтобы сломанные пакеты не были загружены в архив и не потратили зря время работы buildd, вам следует выполнить несколько вещей:

Please note that it is insufficient to only add your package to Packages-arch-specific without making it fail to build on unsupported architectures: A porter or any other person trying to build your package might accidentally upload it without noticing it doesn't work. If in the past some binary packages were uploaded on unsupported architectures, request their removal by filing a bug against ftp.debian.org.

Каждый пакет имеет одного или нескольких сопровождающих. Обычно это люди, которые работают над пакетом и выполняют загрузки новых версий. В некоторых ситуациях бывает полезно, если и другие разработчики смогут загрузить новую версию, например, если они хотят исправить ошибку в пакете, сопровождением которого они не занимаются, и если сопровождающий нуждается в помощи для решения проблем с пакетом. Такие загрузки называются загрузки не-сопровождающими, Non-Maintainer Uploads (NMU).

До выполнения NMU, ответьте на следующие вопросы:

  • Предприняли ли вы NMU для того, чтобы помочь сопровождающему? Поскольку по поводу того, требуется ли сопровождающему помощь, могут возникнуть споры, существует очередь DELAYED, загрузка в которую позволяет сопровождающему отреагировать на вашу загрузку, а также позволяет другим оценить вклад вашей NMU-загрузки.

  • Исправляет ли ваша NMU-загрузка ошибки? (Под "ошибками" подразумеваются любые ошибки, напр. пожелания по созданию пакета для версии из основной ветки разработки, но следует постараться минимизировать проблема сопровождающего.) Исправление косметических проблем или изменение стиля создания пакета (напр., переход с cdbs на dh) в NMU не желательны.

  • Даёте ли вы достаточное количество времени сопровождающему? Когда в системе отслеживания ошибок было прислано сообщение об ошибке? Человек может быть занят одну или две недели, в этом не ничего необычного. Так ли серьёзная ошибка, что её необходимо исправить прямо сейчас, можно ли подождать ещё несколько дней?

  • Насколько вы уверены в своих изменениях? Помните клятву Гиппократа: "Не навреди." Лучше оставить пакет даже с самой серьёзной ошибкой, чем применять к нему неработающую заплату, либо заплату, которая скорее скрывает ошибку, а не решает её. Если вы не уверены на 100% в том, что вы делаете, лучше будет попросить совета у других. Помните, что если вы что-то сломаете во время NMU, многие люди будут недовольны.

  • Выразили ли вы ясно ваше намерение сделать NMU, по меньшей мере в системе отслеживания ошибок? Если вы не получили какого-либо ответа, то попытайтесь связаться с сопровождающим другими способами (напишите сообщение на адрес электронной почты сопровождающего, на его частный адрес электронной почты, через IRC).

  • Если сопровождающий обычно активен и отзывчив, попытались ли вы с ним связаться? Вообще же предпочтительно, чтобы сопровождающие самостоятельно решали проблемы в своих пакетах, нужно дать им возможность проверить вашу заплату и при необходимости исправить её, поскольку они скорее всего лучше осведомлены о потенциальных проблемах, которые могут быть упущены в ходе NMU. Часто время каждого используется значительно лучше, если у сопровождающего будет возможность самому загрузить исправление.

Если вы выполняете NMU, вам для начала следует убедиться, что ваше намерение сделать NMU ясно и понятно. Затем вам необходимо отправить заплату с различиями между текущим пакетом и предполагаемой NMU в системе отслеживания ошибок. Сценарий nmudiff из пакета devscripts может вам в этом помочь.

While preparing the patch, you had better be aware of any package-specific practices that the maintainer might be using. Taking them into account reduces the burden of integrating your changes into the normal package workflow and thus increases the chances that integration will happen. A good place to look for possible package-specific practices is debian/README.source.

Если у вас нет каких-либо веских причин не давать сопровождающему время для самостоятельной работы, вам следует дать последнему это время (например, загрузив пакет в очередь DELAYED). Для задержек рекомендуется использовать следующие значения:

  • Загрузка исправлений критичных для выпуска ошибок, о которых было сообщено более 7 дней назад, сопровождающий не проявлял активности в течении 7 дней, нет никакого указания на то, что исправление находится в стадии подготовки: 0 дней

  • Загрузка исправления только критичных для выпуска ошибок, о которых было сообщено более 7 дней назад: 2 дня

  • Исправление только критичных для выпуска ошибок и важных ошибок: 5 дней

  • Другие NMU: 10 дней

Эти задержки являются лишь примерами. В некоторых случаях, таких как загрузка исправлений безопасности, либо исправлений тривиальных ошибок, блокирующий перемещение пакета, желательно, чтобы исправленный пакет попал в нестабильный выпуск как можно скорее.

Иногда управляющие выпуском принимают решение разрешить NMU с более короткими задержками для некоторого подмножества ошибок (напр., для критичных для выпуска ошибок, о которых было сообщено более 7 дней назад). Кроме того, некоторые сопровождающие добавляют себя в список NMU с низким порогом и разрешают загружать NMU без какой-либо задержки. Но даже в этих случаях лучше всего дать сопровождающему несколько дней на самостоятельную работу и только потом осуществлять загрузку, особенно если заплата ранее не была доступна в системе отслеживания ошибок, либо если вы знаете, что сопровождающий в принципе активен.

После загрузки NMU вы становитесь ответственным за возможные проблемы, которые вы могли создать. Вам необходимо следить за пакетом (чтобы сделать это, подпишитесь на пакет в систем отслеживания пакетов).

Не разрешается бездумно выполнять NMU. Если вы выполняете NMU, и ясно, что сопровождающие активны и приняли бы заплату немного позже, либо если вы игнорируете рекомендации, приведённые в данном документе, ваша загрузка может привести к конфликту с сопровождающим. Вам всегда следует быть готовым к отстаиванию своего решения относительно любой загрузки NMU, которую вы выполняете.

Just like any other (source) upload, NMUs must add an entry to debian/changelog, telling what has changed with this upload. The first line of this entry must explicitly mention that this upload is an NMU, e.g.:

  * Non-maintainer upload.

Присваивание версий при выполнении NMU разница для родных и неродных пакетов.

Если пакет является родным пакетом (без номера ревизии Debian в номере версии), версия должны совпадать с версией загрузки её последним сопровождающим, плюс +nmuX, где X представляет собой счётчик, начинающийся с 1. Если последняя загрузка также была NMU, то счётчик следует увеличить. Например, если текущая версия пакета равна 1.5, то загрузка NMU должна получить версию 1.5+nmu1.

Если пакет не является родным пакетом, вам следует добавить минорный номер версии к части о ревизии Debian номера версии (та часть, которая идёт после последнего знака тире). Этот дополнительный номер должен начинаться с 1. Например, если текущей версией является 1.5-2, то загрузка NMU должна иметь версию 1.5-2.1. Если в ходе NMU создаётся пакет для новой версии из основной ветки разработки, то номер ревизии Debian устанавливается в 0, например, 1.6-0.1.

В обоих случаях если последняя загрузка также была загрузкой NMU, счётчик должен быть увеличен. Например, если текущей версией является 1.5+nmu3 (родной пакет, для которого уже была выполнена загрузка NMU в прошлый раз), загрузка NMU должна получить версию 1.5+nmu4.

Специальная схема версий требуется для того, чтобы избежать срыва работы сопровождающего, поскольку использование целого числа для ревизии Debian потенциально может привести к конфликту с загрузкой, которая уже находится в стадии подготовки самим сопровождающим в то время, как вы выполняете NMU, либо даже уже включена в очередь NEW на ftp. Кроме того, это полезно для визуального выделения того, что пакет в архиве был подготовлен не тем, кто является его официальным сопровождающим.

Если вы загружаете пакет в тестируемый или стабильный выпуски, иногда вам необходимо выполнить "разветвление" древа номера версии. Это делается, например, в случае подготовки загрузок с исправлениями безопасности. Для этого следует использовать версию вида +debXuY, где X представляет собой мажорный номер версии, а Y является счётчиком, начинающимся с 1. Например, поскольку buster (Debian 10) является стабильным выпуском, загрузка NMU для исправления проблем безопасности стабильного выпуска для пакета, имеющего версию 1.5-3 будет иметь версию 1.5-3+deb10u1, а загрузка NMU с исправлением безопасности для bullseye будет иметь версию 1.5-3+deb11u1.

Ожидание ответа на ваш запрос разрешения выполнить NMU не эффективно, так как это предполагает, что тот, кто выполняет NMU, должен будет отвлечься от проблемы, а затем снова вернутся к ней. Очередь DELAYED (см. раздел 5.6.2, «Задержанные загрузки») позволяет разработчику, занимающемуся NMU, в то же самое время выполнять все необходимые задачи. Например, вместо того, чтобы сообщить сопровождающему о том, что вы собираетесь загрузить обновлённый пакет в течении 7 дней, вам следует загрузить пакет в DELAYED/7 и сообщить сопровождающему, что у него имеется 7 дней для того, чтобы отреагировать на это. В течении этого времени сопровождающий может попросить вас ещё немного задержать загрузку, либо отменить её.

Очередь DELAYED не должна использоваться для дополнительного давления на сопровождающего. В частности, важно, что у вас имеется возможность отметить или задержать загрузку ещё немного до того момента, как срок изначальной задержки закончиться, так как сопровождающий не может сам отметить вашу загрузку.

Если вы выполняете NMU в DELAYED, а сопровождающий обновляет пакет до того, как закончится срок задержки, ваша загрузку будет отклонена, поскольку в архиве уже будет доступна более новая версия. В идеале сопровождающий позаботится о включении предлагаемых вами изменений (или по меньшей мере о решении проблем, для решения который предназначаются ваши изменения) в своей загрузке.

Когда кто-то выполняет NMU для вашего пакета, то это означает, что он хочет помочь вам поддерживать пакет в хорошей форме. Это позволяет пользователям быстрее получать исправленные пакеты. Вы можете попросить того, кто выполнил NMU, стать помощником сопровождающего для данного пакета. Когда кто-то выполнил NMU для вашего пакета, это вовсе не плохо; это лишь означает, что пакет интересен достаточному количеству людей, которые готовы работать над ним.

Для подтверждения NMU, добавьте предлагаемые изменения и запись журнала изменений в вашу собственную загрузку. Если вы не подтвердите NMU, добавив запись из журнала изменений NMU в ваш журнал изменений, сообщения об ошибках в системе отслеживания ошибок останутся закрытыми, но будут указаны как актуальные для версии пакета, которую загрузите вы.

Note that if you ever need to revert a NMU that packages a new upstream version, it is recommended to use a fake upstream version like CURRENT+reallyFORMER until one can upload the latest version again. More information can be found in https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly.

Полностью NMU называется NMU исходного кода. Есть и другой тип NMU, а именно двоичные NMU или binNMU. BinNMU также представляет собой загрузку пакета тем, что не является его сопровождающим. Тем не менее, это загрузка исключительно двоичного кода.

При обновлении библиотеки (либо другой зависимости) пакеты, использующие её вероятно потребуется собрать заново. Поскольку изменения исходного кода не требуются, используется тот же самый пакет с исходным кодом.

BinNMU обычно выполняются на buildd по инструкции wanna-build. В файл debian/changelog добавляется запись, объясняющая то, почему потребовалась загрузка, номер версии увеличивается в соответствии с тем, как это описано в разделе 5.10.2.1, «Повторная компиляция или только двоичные NMU». Эту запись не следует включать в следующую загрузку.

Buildd загружает пакеты для своей архитектуры в архив как двоичные загрузки. Строго говоря, они являются binNMU. Тем не менее, обычно они не называются NMU, они не добавляют запись в debian/changelog.

NMUs are uploads of packages by somebody other than their assigned maintainer. There is another type of upload where the uploaded package is not yours: QA uploads. QA uploads are uploads of orphaned packages.

Загрузки, выполняемые командой контроля качества, очень похожи на загрузки обычных сопровождающих: они могут исправлять всё, что угодно, даже незначительные проблемы; присвоение номера версии происходит обычным путём, также нет необходимости использовать задержку при загрузке. Отличие состоит в том, что вы не указаны в полях Maintainer и Uploader данного пакета. Кроме того, запись журнала изменений при загрузке, выполняемой командой контроля качества, содержит специальную первую строку:

 * QA upload.

Если вы хотите выполнить NMU, и у вас складывается впечатление, что сопровождающий не активен, вам следует проверить, является ли данный пакет осиротевшим пакетом (эта информация отображается на странице пакета в системе отслеживания пакетов). При выполнении первой загрузки командой контроля качества в качестве сопровождающего устанавливается Debian QA Group <packages@qa.debian.org>. Для осиротевших пакетов, загрузка которых командой контроля качества ещё не выполнялась, в качестве сопровождающего имеют своего старого сопровождающего. Имеется список таких пакетов: https://qa.debian.org/orphaned.html.

Instead of doing a QA upload, you can also consider adopting the package by making yourself the maintainer. You don't need permission from anybody to adopt an orphaned package; you can just set yourself as maintainer and upload the new version (see Раздел 5.9.5, «Усыновление пакета»).

Sometimes you are fixing and/or updating a package because you are member of a packaging team (which uses a mailing list as Maintainer or Uploader; see Раздел 5.13, «Совместное сопровождение») but you don't want to add yourself to Uploaders because you do not plan to contribute regularly to this specific package. If it conforms with your team's policy, you can perform a normal upload without being listed directly as Maintainer or Uploader. In that case, you should start your changelog entry with the following line:

 * Team upload.

Package salvaging is the process by which one attempts to save a package that, while not officially orphaned, appears poorly maintained or completely unmaintained. This is a weaker and faster procedure than orphaning a package officially through the powers of the MIA team. Salvaging a package is not meant to replace MIA handling, and differs in that it does not imply anything about the overall activity of a maintainer. Instead, it handles a package maintainership transition for a single package only, leaving any other package or Debian membership or upload rights (when applicable) untouched.

Note that the process is only intended for actively taking over maintainership. Do not start a package salvaging process when you do not intend to maintain the package for a prolonged time. If you only want to fix certain things, but not take over the package, you must use the NMU process, even if the package would be eligible for salvaging. The NMU process is explained in Раздел 5.11, «Загрузки не-сопровождающим (NMU)».

Another important thing to remember: It is not acceptable to hijack others' packages. If followed, this salvaging process will help you to ensure that your endeavour is not a hijack but a (legal) salvaging procedure, and you can counter any allegations of hijacking with a reference to this process. Thanks to this process, new contributors should no longer be afraid to take over packages that have been neglected or entirely forgotten.

The process is split into two phases: In the first phase you determine whether the package in question is eligible for the salvaging process. Only when the eligibility has been determined you may enter the second phase, the actual package salvaging.

For additional information, rationales and FAQs on package salvaging, please visit the Salvaging Packages page on the Debian wiki.

If and only if a package has been determined to be eligible for package salvaging, any prospective maintainer may start the following package salvaging procedure.

  1. Open a bug with the severity "important" against the package in question, expressing the intent to take over maintainership of the package. For this, the title of the bug should start with ITS: package-name[5]. You may alternatively offer to only take co-maintenance of the package. When you file the bug, you must inform all maintainers, uploaders and if applicable the packaging team explicitly by adding them to X-Debbugs-CC. Additionally, if the maintainer(s) seem(s) to be generally inactive, please inform the MIA team by adding mia@qa.debian.org to X-Debbugs-CC as well. As well as the explicit expression of the intent to salvage, please also take the time to document your assessment of the eligibility in the bug report, for example by listing the criteria you've applied and adding some data to make it easier for others to assess the situation.

  2. In this step you need to wait in case any objections to the salvaging are raised; the maintainer, any current uploader or any member of the associated packaging team of the package in question may object publicly in response to the bug you've filed within 21 days, and this terminates the salvaging process.

    The current maintainers may also agree to your intent to salvage by filing a (signed) public response to the the bug. They might propose that you become a co-maintainer instead of the sole maintainer. On team maintained packages, a member of the associated team can accept your salvaging proposal by sending out a signed agreement notice to the ITS bug, alternatively inviting you to become a new co-maintainer of the package. The team may require you to keep the package under the team's umbrella, but then may ask or invite you to join the team. In any of these cases where you have received the OK to proceed, you can upload the new package immediately as the new (co-)maintainer, without the need to utilise the DELAYED queue as described in the next step.

  3. After the 21 days delay, if no answer has been sent to the bug from the maintainer, one of the uploaders or team, you may upload the new release of the package into the DELAYED queue with a minimum delay of seven days. You should close the salvage bug in the changelog and you must also send an nmudiff to the bug ensuring that copies are sent to the maintainer and any uploaders (including teams) of the package by CC'ing them in the mail to the BTS.

    During the waiting time of the DELAYED queue, the maintainer can accept the salvaging, do an upload themselves or (ask to) cancel the upload. The latter two of these will also stop the salvaging process, but the maintainer must reply to the salvaging bug with more information about their action.

Совместное сопровождение представляет собой термин, описывающий разделение обязанностей по сопровождению пакета Debian между несколькими людьми. Эта совместная работа почти всегда является отличной идеей, поскольку её результатом обычно является более высокое качество пакета и более быстрое исправление ошибок. Настоятельно рекомендуется, чтобы пакет с приоритетом standard, а также пакеты, являющиеся частью базового набора пакетов, имели несколько сопровождающих.

Обычно имеется главный сопровождающий и один или больше помощников. Главный сопровождающий является тем, чьё имя указано в поле Maintainer файла debian/control. Помощники сопровождающего — это все остальные сопровождающие, обычно они указаны в поле Uploaders файла debian/control.

В наиболее простом виде процесс добавления новых помощников сопровождающий крайне лёгок:

Другой формой совместного сопровождения является командное сопровождение, которое рекомендуется в случае если вы сопровождаете несколько пакетов вместе группой одних и тех же разработчиков. В этом случае на поля Maintainer и Uploaders каждого пакеты следует обратить особое внимание. Рекомендуется выбрать одну из двух следующих схем:

  1. Поместите в поле Maintainer члена команды, который будет ответственен за данный пакет. В поле Uploaders поместите адрес списка рассылки, а также тех членов команды, которые также будут следить за пакетов.

  2. Put the mailing list address in the Maintainer field. In the Uploaders field, put the team members who care for the package. In this case, you must make sure the mailing list accepts bug reports without any human interaction (like moderation for non-subscribers).

В любом случае не следует помещать всех членов команды в поле Uploaders. Это приводит к путанице — в обзорный список пакетов разработчика (см. раздел 4.11, «Обзор пакетов разработчика») попадают пакеты, о который данный разработчик фактически не заботится, и создаёт у пользователей ложное чувство того, что пакет хорошо сопровождается. По той же самой причине члены команды не должны добавлять себя в поле Uploaders только потому, что они загрузили данный пакет один раз, они могут выполнить “командную загрузку” (см. раздел 5.11.7, «NMU и командные загрузки»). И наоборот, не следует оставлять пакет только с одним адресом списка рассылки в поле Maintainer, когда поле Uploaders пусто.

Сценарии, обновляющие тестируемый выпуск, запускаются дважды каждый день, сразу же после установки обновлённых пакетов; эти сценарии имеют имя britney. Они создают файлы Packages для тестируемого выпуска, но делают они это разумным способом; они пытаются избежать противоречивости и использовать только те пакеты, которые не имеют ошибок.

Включение пакета из нестабильного выпуска выполняется в соответствии со следующими условиями:

Чтобы узнать, продвигается пакет к переходу в тестируемый выпуск или нет, см. вывод сценария тестируемого выпуска на веб-странице тестируемого выпуска, либо используйте программу grep-excuses, которая является частью пакета devscripts. Данная утилита легко может использоваться в crontab(5) для того, чтобы у вас всегда имелась информация о продвижении ваших пакетов в тестируемый выпуск.

Файл update_excuses не всегда содержит точную причину того, почему пакет был отклонён; вам может потребоваться выяснить это самостоятельно, проверяя, что может сломаться из-за добавления вашего пакета. Веб-страница тестируемого выпуска содержит немного больше информации об обычных проблемах, которые могут вызывать подобные затруднения.

Бывает так, что некоторые пакет никогда не включаются в тестируемый выпуск из-за того, что набор взаимных зависимостей слишком сложен и не может быть разобран сценариями. Подробности см. ниже.

Some further dependency analysis is shown on https://release.debian.org/migration/ — but be warned: this page also shows build dependencies that are not considered by britney.

For the testing migration script, outdated means: There are different versions in unstable for the release architectures (except for the architectures in outofsync_arches; outofsync_arches is a list of architectures that don't keep up (in britney.py), but currently, it's empty). Outdated has nothing whatsoever to do with the architectures this package has in testing.

Рассмотрим следующий пример:

  alpha arm
testing 1 -
unstable 1 2

The package is out of date on alpha in unstable, and will not go to testing. Removing the package would not help at all; the package is still out of date on alpha, and will not propagate to testing.

Тем не менее, если сопровождающий ftp удаляет пакет в нестабильном выпуске (здесь — на архитектуре arm):

  alpha arm hurd-i386
testing 1 1 -
unstable 2 - 1

В этом случае пакет считается обновлённым на всех выпускаемых архитектурах в нестабильном выпуске (дополнительная архитектура hurd-i386 не имеет значения, поскольку она не является выпускаемой архитектурой).

Время от времени возникает вопрос о том, можно ли разрешить переход пакетов, которые ещё не были собраны на всех архитектурах. Нет. Просто нет и всё. (За исключением случая, если вы сопровождаете glibc или что-то подобное.)

Если вам интересны подробности, то britney работает следующим образом:

Просматриваются пакеты на предмет выявления того, являются они корректными кандидатами или нет. Это даёт нам список оснований для отказа в обновлении. Наиболее частыми основаниями того, почему пакет не рассматривается для обновления, являются то, что он слишком нов, имеет критичные для выпуска ошибки, устарел на каких-то архитектурах. Для этой части britney у управляющих выпуском имеются различные инструменты, называемые подсказками (см. ниже), которые используются для того, чтобы заставить britney рассмотреть данный пакет.

Далее начинается более сложная часть. Britney пытается обновить тестируемый выпуск путём установки корректных кандидатов. Для этого britney пытается добавить каждого корректного кандидата в тестируемый выпуск. Если число неустанавливаемых пакетов в тестируемом выпуске не увеличивается, то пакет принимается. С этой точки зрения принятый пакет считается частью тестируемого выпуска, такой частью, что все последующий проверки установок будут включать в себя этот пакет. Подсказки выпускающей команды обрабатываются после или до этой основной работы в зависимости от типа подсказок.

Если вы хотите ознакомиться с дополнительными подробностями, вы можете прочитать https://ftp-master.debian.org/testing/update_output/.

Подсказки доступны в https://ftp-master.debian.org/testing/hints/, также там вы можете найти описание. При помощи подсказок выпускающая команда Debian может блокировать или разблокировать пакеты, замедлять или ускорять переход пакетов в тестируемый выпуск, удалять пакеты из тестируемого выпуска, принимать загрузки в testing-proposed-updates, либо изменять срочность загрузки.

Тестируемый выпуск получает пакеты из нестабильного выпуска в соответствии с описанными ранее правилами. Тем не менее, в некоторых случаях необходимо загружать пакеты, собранные только для тестируемого выпуска. Для этого вы можете использовать загрузку в testing-proposed-updates.

Keep in mind that packages uploaded there are not automatically processed; they have to go through the hands of the release manager. So you'd better have a good reason to upload there. In order to know what a good reason is in the release managers' eyes, you should read the instructions that they regularly give on .

Вам не следует загружать в testing-proposed-updates, если вы можете обновить ваши пакеты через нестабильный выпуск. Если вы не можете этого сделать (например, из-за того, что у вас имеется более новая версия в нестабильном выпуске), вы можете использовать эту возможность. Однако рекомендуется сначала попросить на это разрешение у управляющего выпуском. Даже если пакет заморожен обновления через нестабильный выпуск всё равно возможны, если загрузка через нестабильный выпуск не тянет за собой какие-либо новые зависимости.

Номера версий обычно выбираются путём добавления +debXuY, где X представляет собой мажорный номер выпуска Debian, а Y является счётчиком, начинающимся с 1. Напр., 1:2.4.3-4+deb10u1.

Убедитесь, что в вашей загрузке вы ничего не пропустили из следующего списка:

  • Убедитесь, что ваш пакет действительно должен пройти через testing-proposed-updates, и что он не может пройти через нестабильный выпуск;

  • Убедитесь, что вы включили в пакет лишь минимальное число изменений;

  • Убедитесь, что вы включили соответствующее объяснение в журнал изменений пакета;

  • Убедитесь, что вы указали кодовое-имя тестируемого выпуска (напр., bullseye) в качестве целевого выпуска;

  • Убедитесь, что вы собрали и протестировали ваш пакет в тестируемом, а не в нестабильном выпуске;

  • Убедитесь, что номер версии пакета выше номера версии, входящей в тестируемый выпуск и в testing-proposed-updates, а также ниже, чем в нестабильном выпуске;

  • После загрузки и успешной сборки на всех платформах, свяжитесь с выпускающей командой по адресу и попросите их одобрить вашу загрузку.

Структура архивов выпусков такова, что они могут содержать только одну версию пакета; пакет определяется его именем. Поэтому, когда пакет с исходным кодом acmefoo устанавливается в тестируемый выпуск вместе с соответствующими двоичными пакетами acme-foo-bin, acme-bar-bin, libacme-foo1 и libacme-foo-dev, старая версии пакетов удаляются.

However, the old version may have provided a binary package with an old soname of a library, such as libacme-foo0. Removing the old acmefoo will remove libacme-foo0, which will break any packages that depend on it.

Evidently, this mainly affects packages that provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <=, or << varieties.

When the set of binary packages provided by a source package changes in this way, all the packages that depended on the old binaries will have to be updated to depend on the new binaries instead. Because installing such a source package into testing breaks all the packages that depended on it in testing, some care has to be taken now: all the depending packages must be updated and ready to be installed themselves so that they won't be broken, and, once everything is ready, manual intervention by the release manager or an assistant is normally required.

Если у вас имеются подобные проблемы со сложной группой пакетов, свяжитесь с or for help.



[3] См. Руководство по политике Debian для получения советов о том, к какому разделу относится тот или иной пакет.

[4] В прошло подобные NMU использовали номер третьего уровня в части Debian редакции для обозначения статуса повторной компиляции; тем не менее, этот синтаксис был двусмыслен в случае родных пакетов и не позволяя правильно определять порядок заново скомпилированных NMU, NMU исходного кода и NMU безопасности одного и того же пакета, потому он был отброшен и заменён новым синтаксисом.

[5] ITS is shorthand for "Intend to Salvage"