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

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

5.1. Новые пакеты

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

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

You should set the subject of the bug to ITP: foo -- short description, substituting the name of the new package for foo. The severity of the bug report must be set to wishlist. Please send a copy to debian-devel@lists.debian.org by using the X-Debbugs-CC header (don't use CC:, because that way the message's subject won't indicate the bug number). If you are packaging so many new packages (>10) that notifying the mailing list in separate messages is too disruptive, send a summary after filing the bugs to the debian-devel list instead. This will inform the other developers about upcoming packages and will allow a review of your description and package name.

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

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

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

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

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

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

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

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

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

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

5.2. Запись изменений в пакете

Changes that you make to the package need to be recorded in the debian/changelog file, for human users to read and comprehend. These changes should provide a concise description of what was changed, why (if it's in doubt), and note if any bugs were closed. They also record when the packaging was completed. This file will be installed in /usr/share/doc/package/changelog.Debian.gz, or /usr/share/doc/package/changelog.gz for native packages.

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

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

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

* New upstream release.

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

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

5.3. Тестирование пакета

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

• Run lintian over the package. You can run lintian as follows: lintian -v package-version.changes. This will check the source package as well as the binary package. If you don't understand the output that lintian generates, try adding the -i switch, which will cause lintian to output a very verbose description of the problem.

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

  Для получения дополнительной информации о команде lintian, см. lintian.

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

• Install the package and make sure the software works in an up-to-date unstable system.

• Upgrade the package from an older version to your new version.

• Удалите пакет, затем заново установите его.

• Installing, upgrading and removal of packages can either be tested manually or by using the piuparts tool.

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

5.4. Схема пакета с исходным кодом

Имеется два типа пакетов 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.

5.5. Выбор выпуска

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

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

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

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

5.5.1. Специальный случай: загрузка в стабильный и предыдущий стабильный выпуски

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

Uploads to a supported stable release should target their suite name in the changelog, i.e. bookworm or bullseye. You should normally use reportbug and the release.debian.org pseudo-package to send a source debdiff, rationale and associated bug numbers to the stable release managers, and await a request to upload or further information.

If you are confident that the upload will be accepted without changes, please feel free to upload at the same time as filing the release.debian.org bug. However if you are new to the process, we would recommend getting approval before uploading so you get a chance to see if your expectations align with ours.

Either way, there must be an accompanying bug for tracking, and your upload must comply with these acceptance criteria defined by the the stable release managers. These criteria are designed to help the process be as smooth and frustration-free as possible.

• The bug you want to fix in stable must be fixed in unstable already (and not waiting in NEW or the delayed queue).

• The bug should be of severity "important" or higher.

• Bug meta-data - particularly affected versions - must be up to date.

• Fixes must be minimal and relevant and include a sufficiently detailed changelog entry.

• A source debdiff of the proposed change must be included in your request (not just the raw patches or "a debdiff can be found at $URL").

• The proposed package must have a correct version number (e.g. ...+deb12u1 for bookworm or +deb11u1 for bullseye) and you should be able to explain what testing it has had. See the Debian Policy for the version number: https://www.debian.org/doc/debian-policy/ch-controlfields.html#special-version-conventions

• The update must be built in an stable environment or chroot (or oldstable if you target that).

• Fixes for security issues should be co-ordinated with the security team, unless they have explicitly stated that they will not issue an DSA for the bug (e.g. via a "no-dsa" marker in the Debian Security Tracker).

It is recommended to use reportbug as it eases the creation of bugs with correct meta-data. The release team makes extensive use of usertags to sort and manage requests and incorrectly tagged reports may take longer to be noticed and processed.

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

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 (DSA) are automatically copied to the appropriate proposed-updates archive when the advisory is released. See Работа с ошибками, связанными с безопасностью 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.

5.5.2. Special case: the stable-updates suite

Sometimes the stable release managers will decide that an update to stable should be made available to users sooner than the next scheduled point release. In such cases, they can copy the update to the stable-updates suite, use of which is enabled by the installer by default.

Initially, the process described in Специальный случай: загрузка в стабильный и предыдущий стабильный выпуски. should be followed as usual. If you think that the upload should be released via stable-updates, mention this in your request. Examples of circumstances in which the upload may qualify for such treatment are:

• The update is urgent and not of a security nature. Security updates will continue to be pushed through the security archive. Examples include packages broken by the flow of time (c.f. spamassassin and the year 2010 problem) and fixes for bugs introduced by point releases.

• The package in question is a data package and the data must be updated in a timely manner (e.g. tzdata).

• Fixes to leaf packages that were broken by external changes (e.g. video downloading tools and tor).

• Packages that need to be current to be useful (e.g. clamav).

• Uploads to stable-updates should target their suite name in the changelog as usual, e.g. bookworm.

Once the upload has been accepted to proposed-updates and is ready for release, the stable release managers will then copy it to the stable-updates suite and issue a Stable Update Announcement (SUA) via the debian-stable-announce mailing list.

Any updates released via stable-updates will be included in stable with the next point release as usual.

5.5.3. Специальный случай: загрузка в testing/testing-proposed-updates

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

5.6. Загрузка пакета

5.6.1. Source and binary uploads

Each upload to Debian consists of a signed .changes file describing the requested change to the archive, plus the source and binary package files that are referenced by the .changes file.

If possible, the version of a package that is uploaded should be a source-only changes file. These are typically named *_source.changes, and reference the source package, but no binary .deb or .udeb packages. All of the corresponding architecture-dependent and architecture-independent binary packages, for all architectures, will be built automatically by the build daemons in a controlled and predictable environment (see wanna-build for more details). However, there are several situations where this is not possible.

The first upload of a new source package (see Новые пакеты) must include binary packages, so that they can be reviewed by the archive administrators before they are added to Debian.

If new binary packages are added to an existing source package, then the first upload that lists the new binary packages in debian/control must include binary packages, again so that they can be reviewed by the archive administrators before they are added to Debian. It is preferred for these uploads to be done via the experimental suite.

Uploads that will be held for review in other queues, such as packages being added to the *-backports suites, might also require inclusion of binary packages.

The build daemons will automatically attempt to build any main or contrib package for which the build-dependencies are available. Packages in non-free and non-free-firmware will not be built by the build daemons unless the package has been marked as suitable for auto-building (see Отмечаем несвободные пакеты как собираемые автоматически (auto-buildable)).

The build daemons only install build-dependencies from the main archive area. This means that if a source package has build-dependencies that are in the contrib, non-free or non-free-firmware archive areas, then uploads of that package need to include prebuilt binary packages for every architecture that will be supported. By definition this can only be the case for source packages that are themselves in the contrib, non-free or non-free-firmware archive areas.

Bootstrapping a new architecture, or a new version of a package with circular dependencies (such as a self-hosting compiler), will sometimes also require an upload that includes binary packages.

Binary packages in the main archive area that were not built by Debian's official build daemons will not usually be allowed to migrate from unstable to testing, so an upload that contains binary packages built by the package's maintainer must usually be followed by a source-only upload after the binary upload has been accepted. This restriction does not apply to contrib, non-free or non-free-firmware packages.

5.6.2. Загрузка на ftp-master

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.

For removing packages or cancelling an upload, please see ftp://ftp.upload.debian.org/pub/UploadQueue/README and the Debian package dcut.

Finally, you should think about the status of your package with relation to testing before uploading to unstable. If you have a version in unstable waiting to migrate then it is generally a good idea to let it migrate before uploading another new version. You should also check the Система отслеживания пакетов Debian for transition warnings to avoid making uploads that disrupt ongoing transitions.

5.6.3. Задержанные загрузки

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

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

With dput, you can use the --delayed DELAY parameter to put the package into one of the queues.

5.6.4. Загрузки безопасности

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. For details, please see Работа с ошибками, связанными с безопасностью.

5.6.5. Другие очереди загрузки

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

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

5.6.6. Notifications

Сопровождающие архива 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.

5.7. Определение раздела для пакета, подраздела и приоритета

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

5.8. Работа с ошибками

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

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

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

5.8.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 подобно следующей, если вы хотите получить еженедельные сообщения с обзором всех открытых сообщений об ошибках в ваших пакетах:

# ask for weekly reports of bugs in my packages
0 17 * * fri   echo "index maint address" | mail request@bugs.debian.org

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

5.8.2. Ответ на ошибки

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 123@bugs.debian.org 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 123-submitter@bugs.debian.org 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 123-submitter@bugs.debian.org. Otherwise you should include 123@bugs.debian.org so that you also reach the package maintainer.

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

Как только вы закончили работать с сообщением об ошибке (напр., исправили ошибку) отметьте его как завершённое (закройте его), отправив сообщение с объяснением по адресу 123-done@bugs.debian.org. Если вы исправили ошибку путём изменения и загрузки пакета, вы можете автоматизировать закрытие сообщения об ошибке как это описано в Когда ошибки исправляются путём новых загрузок.

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

5.8.3. Bug housekeeping

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

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

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

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

   If the bug submitter disagrees with your decision to close the bug, they may reopen it until you find an agreement on how to handle it. If you don't find any, you may want to tag the bug wontfix to let people know that the bug exists but that it won't be corrected. Please make sure that the bug submitter understands the reasons for your decision by adding an explanation to the message that adds the wontfix tag.

   If this situation is unacceptable, you (or the submitter) may want to require a decision of the technical committee by filing a new bug against the tech-ctte pseudo-package with a summary of the situation. Before doing so, please read the recommended procedure.

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

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

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

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

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

6. Если ошибка касается создания пакета, вам следует её исправить. Если вы не можете сами исправить её, то отметьте сообщение об ошибке тегом help. Кроме того, вы можете попросить о помощи в debian-devel@lists.debian.org или debian-qa@lists.debian.org. Если это проблема основной ветки разработки, вам следует переслать сообщение об ошибке автору основной ветки. Простой пересылки сообщения об ошибке не достаточно, вам следует проверять каждый выпуск основной ветки на предмет исправления этой ошибки. Если ошибка была исправлена, вам нужно просто закрыть сообщение об ошибке, в противном случае вам следует напомнить автору об ошибке. Если у вас имеются требуемые навыки, вы можете подготовить заплату, исправляющую ошибку и отправить её автору основной ветки. Убедитесь, что вы отправили заплату в систему отслеживания ошибок и пометили сообщение об ошибке тегом 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.

If you happen to mistype a bug number or forget a bug in the changelog entries, don't hesitate to undo any damage the error caused. To reopen wrongly closed bugs, send a reopen XXX command to the bug tracking system's control address, control@bugs.debian.org. To close any remaining bugs that were fixed by your upload, email the .changes file to XXX-done@bugs.debian.org, where XXX is the bug number, and put Version: YYY and an empty line as the first two lines of the body of the email, where YYY is the first version where the bug has been fixed.

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

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

5.8.5. Работа с ошибками, связанными с безопасностью

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

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

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

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

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

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

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

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

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

5.8.5.1. Debian Security Tracker

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

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

5.8.5.2. Конфиденциальность

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

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

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

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

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

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

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

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

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

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

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

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

5.8.5.3. Рекомендации по безопасности

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

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

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

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

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

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

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

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

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

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

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

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

5.8.5.4. Подготовка пакетов для решения проблем безопасности

Вы можете помочь команде безопасности, если предоставите им исправления пакетов, подходящие для рекомендации по безопасности для стабильного выпуска 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, см. debdiff).

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

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

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

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

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

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

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

5.8.5.5. Загрузка исправленного пакета

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.

5.9. Перемещение, удаление, переименование, придание статуса осиротевшего, усыновление и повторное введение пакетов

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

5.9.1. Перемещение пакетов

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

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

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

5.9.2. Удаление пакетов

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 Удаление из тестируемого выпуска.)

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

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

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

Further information relating to these and other package removal related topics may be found at https://wiki.debian.org/ftpmaster_Removalsand https://qa.debian.org/howto-remove.html.

If in doubt concerning whether a package is disposable, email debian-devel@lists.debian.org asking for opinions. Also of interest is the apt-cache program from the apt package. When invoked as apt-cache showpkg package, the program will show details for package, including reverse depends. Other useful programs include apt-cache rdepends, apt-rdepends, build-rdeps (in the devscripts package) and grep-dctrl. Removal of orphaned packages is discussed on debian-qa@lists.debian.org.

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

5.9.2.1. Удаление пакетов из каталога Incoming (каталога входящих пакетов)

In the past, it was possible to remove packages from incoming. However, with the introduction of the new incoming system, this is no longer possible. [4] Instead, you have to upload a new revision of your package with a higher version than the package you want to replace. Both versions will be installed in the archive but only the higher version will actually be available in unstable since the previous version will immediately be replaced by the higher. However, if you do proper testing of your packages, the need to replace a package should not occur too often anyway.

5.9.3. Замена или переименование пакетов

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

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

5.9.4. Придание статуса осиротевшего пакета

If you can no longer maintain a package, you need to inform others, and see that the package is marked as orphaned. You should set the package maintainer to Debian QA Group <packages@qa.debian.org> and submit a bug report against the pseudo package wnpp. The bug report should be titled O: package -- short description indicating that the package is now orphaned. The severity of the bug should be set to normal; if the package has a priority of standard or higher, it should be set to important. If you feel it's necessary, send a copy to debian-devel@lists.debian.org by putting the address in the X-Debbugs-CC: header of the message (no, don't use CC:, because that way the message's subject won't indicate the bug number).

If you just intend to give the package away, but you can keep maintainership for the moment, then you should instead submit a bug against wnpp and title it RFA: package -- short description. RFA stands for Request For Adoption.

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

5.9.5. Усыновление пакета

Список пакетов, которым требуются новые сопровождающие, доступен на странице Требующих доработки и будущих пакетов (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 Package Salvaging. If you have reason to believe a maintainer is no longer active at all, see Работа с неактивными и/или недоступными сопровождающими.

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, хотя на это может потребоваться несколько часов после выполнения загрузки. Если вы пока не собираетесь загружать новую версию, вы можете использовать информацию из Система отслеживания пакетов Debian для получения сообщений об ошибках. Тем не менее, убедитесь, что старый сопровождающий не против того факта, что он будет получать сообщения об ошибках в течении какого-то времени.

5.9.6. Повторное добавление пакетов

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

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

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

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

You should base your work on the latest packaging available that is suitable. That might be the latest version from unstable, which will still be present in the snapshot archive.

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

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

Package removals from unstable also trigger marking the package as removed in the Debian 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.

5.10. Работа на переносом и перенос пакетов

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.

5.10.1. Будьте добры к тем, кто занимается переносом

У тех, кто занимается переносом, трудная и необычная задача, поскольку им необходимо работать с большим объёмом пакетов. В идеале каждый пакет с исходным кодом должен собираться прямо из коробки. К сожалению, зачастую это не так. Данный раздел содержит список „ошибочек“, которые часть совершают сопровождающие 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 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 pbuilder).

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

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

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

3. Make sure your source package is correct. Do dpkg-source -x package.dsc to make sure your source package unpacks properly. Then, in there, try building your package from scratch with 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.

5.10.2. Руководство для загрузок теми, кто занимается переносом

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

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

The way to invoke dpkg-buildpackage is as dpkg-buildpackage -B -m porter-email. Of course, set porter-email to your email address. This will do a binary-only build of only the architecture-dependent portions of the package, using the binary-arch target in debian/rules.

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

5.10.2.1. Повторная компиляция или только двоичные NMU

Иногда первоначальная загрузка, связанная с переносом, проблематична из-за того, что окружение, в котором был собран пакет, не было достаточно хорошо (устаревшая или не используемая более библиотека, плохой компилятор и т. д.). Тогда вам может потребоваться заново скомпилировать пакет в обновлённом окружении. Тем не менее, в этом случае вам придётся увеличить номер версии пакета, чтобы старый плохой пакет был заменён на новый в архиве 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. [2]

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

5.10.2.2. Когда следует делать NMU, если вы занимаетесь переносом

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

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

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

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

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

5.10.3. Инфраструктура переноса и автоматизация

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

5.10.3.1. Списки рассылки и веб-страницы

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

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

5.10.3.2. Инструменты переноса

Описания некоторых инструментов переноса могут быть найдены в Инструменты для переноса.

5.10.3.3. wanna-build

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 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 формат.

5.10.4. Если ваш пакет не может быть перенесён

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

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

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

  Кроме того, если вы убеждены, что список поддерживаемых архитектур вполне постоянен, вам следует изменить any на список поддерживаемых архитектур в debian/control. При этом способе сборка опять же завершиться неудачно, пользователю будет сообщено об этом, даже хотя попытки сборки не было.

• Для того, чтобы ПО для автоматической сборки не пыталось без необходимости на то собрать ваш пакет, в Packages-arch-specific должен быть включён список, используемый сценарием wanna-build. Текущая версия доступна как https://wiki.debian.org/PackagesArchSpecific; с кем можно связаться по поводу изменений см. в начале файла.

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.

5.10.5. Отмечаем несвободные пакеты как собираемые автоматически (auto-buildable)

By default packages from the non-free and non-free-firmware sections are not built by the autobuilder network (mostly because the license of the packages could disapprove). To enable a package to be built, you need to perform the following steps:

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

2. Добавьте XS-Autobuild: yes в заголовок файла debian/control;

3. Send an email to non-free@buildd.debian.org and explain why the package can legitimately and technically be auto-built.

5.11. Загрузки не-сопровождающим (NMU)

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

5.11.1. Когда и как делать NMU

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

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

• Does your NMU really fix bugs? ("Bugs" means any kind of bugs, e.g. wishlist bugs for packaging a new upstream version, but care should be taken to minimize the impact to the maintainer.) Fixing cosmetic issues or changing the packaging style in NMUs is discouraged.

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

• Насколько вы уверены в своих изменениях? Помните клятву Гиппократа: "Не навреди." Лучше оставить пакет даже с самой серьёзной ошибкой, чем применять к нему неработающую заплату, либо заплату, которая скорее скрывает ошибку, а не решает её. Если вы не уверены на 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 дней

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

Sometimes, release managers decide to encourage NMUs with shorter delays for a subset of bugs (e.g release-critical bugs older than 7 days). Also, some maintainers list themselves in the Low Threshold NMU list, and accept that NMUs are uploaded without delay. But even in those cases, it's still a good idea to give the maintainer a few days to react before you upload, especially if the patch wasn't available in the BTS before, or if you know that the maintainer is generally active.

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

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

5.11.2. NMU и файл debian/changelog

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. Например, поскольку bookworm (Debian 12) является стабильным выпуском, загрузка NMU для исправления проблем безопасности стабильного выпуска для пакета, имеющего версию 1.5-3 будет иметь версию 1.5-3+deb12u1, а загрузка NMU с исправлением безопасности для trixie будет иметь версию 1.5-3+deb13u1.

5.11.3. Использование очереди DELAYED/

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

You can cancel your upload using dcut. In case you uploaded foo_1.2-1.1_all.changes to a DELAYED queue, you can run dcut cancel foo_1.2-1.1_all.changes to cancel your upload. The .changes file does not need to be present locally as you instruct dcut to upload a command file removing a remote filename. The .changes file name is the same that you used when uploading.

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

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

5.11.4. NMU с точки зрения сопровождающего

Когда кто-то выполняет 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.

5.11.5. NMU исходного кода и двоичные NMU (binNMU)

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

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

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

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

5.11.6. NMU и загрузки командой контроля качества

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.11.7. NMU и командные загрузки

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 Совместное сопровождение) 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.

5.12. Package Salvaging

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 Загрузки не-сопровождающим (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.

5.12.1. When a package is eligible for package salvaging

A package becomes eligible for salvaging when it has been neglected by the current maintainer. To determine that a package has really been neglected by the maintainer, the following indicators give a rough idea what to look for:

• NMUs, especially if there has been more than one NMU in a row.

• Bugs filed against the package do not have answers from the maintainer.

• Upstream has released several versions, but despite there being a bug entry asking for it, it has not been packaged.

• There are QA issues with the package.

You will have to use your judgement as to whether a given combination factors constitutes neglect; in case the maintainer disagrees they have only to say so (see below). If you're not sure about your judgement or simply want to be on the safe side, there is a more precise (and conservative) set of conditions in the Package Salvaging wiki page. These conditions represent a current Debian consensus on salvaging criteria. In any case you should explain your reasons for thinking the package is neglected when you file an Intent to Salvage bug later.

5.12.2. How to salvage a package

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 [3]. 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.

5.13. Совместное сопровождение

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

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

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

• Set up the co-maintainer with access to the sources you build the package from. Generally this implies you are using a network-capable version control system, such as Git. Salsa (see salsa.debian.org: Git repositories and collaborative development platform) provides Git repositories, amongst other collaborative tools.

• Добавьте имя и адрес электронной почты вашего помощника в поле Uploaders из первого раздела файла debian/control.

  Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
  

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

Другой формой совместного сопровождения является командное сопровождение, которое рекомендуется в случае если вы сопровождаете несколько пакетов вместе группой одних и тех же разработчиков. В этом случае на поля 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. Это приводит к путанице — в обзорный список пакетов разработчика (см. Обзор пакетов разработчика) попадают пакеты, о который данный разработчик фактически не заботится, и создаёт у пользователей ложное чувство того, что пакет хорошо сопровождается. По той же самой причине члены команды не должны добавлять себя в поле Uploaders только потому, что они загрузили данный пакет один раз, они могут выполнить “командную загрузку” (см. NMU и командные загрузки). И наоборот, не следует оставлять пакет только с одним адресом списка рассылки в поле Maintainer, когда поле Uploaders пусто.

5.14. Тестируемый выпуск

5.14.1. Основы

Обычно пакеты устанавливаются в тестируемый выпуск после того, как они пройдут некоторое тестирование в нестабильном выпуске.

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

5.14.2. Обновления из нестабильного выпуска

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

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

• The package must have been available in unstable for a certain number of days, see Selecting the upload urgency. Please note that the urgency is sticky, meaning that the highest urgency uploaded since the previous testing transition is taken into account;

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

• Пакет должен быть доступен на всех архитектурах, на которых он ранее был собран в нестабильном выпуске. Утилита dak ls может помочь проверить эту информацию;

• Пакет не должен ломать зависимости какого-либо уже доступного в тестируемом выпуске пакета;

• Пакеты, от которых зависит данный пакет, должны либо быть доступны в тестируемом выпуске, либо должны быть приняты в тестируемый выпуск одновременно с этим пакетом (эти пакеты будут приняты в случае, если они удовлетворяют всем необходимым критериям);

• Фаза проекта. Напр., автоматические переходы отключаются во время заморозки тестируемого выпуска.

Чтобы узнать, продвигается пакет к переходу в тестируемый выпуск или нет, см. вывод сценария тестируемого выпуска на веб-странице тестируемого выпуска, либо используйте программу 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.

5.14.2.1. Устаревание

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 или что-то подобное.)

5.14.2.2. Удаление из тестируемого выпуска

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

Of course, there is another reason to remove a package from testing: it's just too buggy (and having a single RC-bug is enough to be in this state).

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

5.14.2.3. Круговые зависимости

Ситуация, которая не может быть правильно обработана britney, заключает в том, что пакет a зависит от новой версии пакета b, и наоборот.

Пример:

	testing	unstable
a	1; depends: b=1	2; depends: b=2
b	1; depends: a=1	2; depends: a=2

Ни пакет a, ни пакет b не рассматриваются для обновления.

В настоящее время такая ситуация требует вмешательства выпускающей команды. Свяжитесь с ними, отправив сообщение по адресу debian-release@lists.debian.org, если такая ситуация возникла для одного из ваших пакетов.

5.14.2.4. Влияние пакета в тестируемом выпуске

Generally, there is nothing that the status of a package in testing means for transition of the next version from unstable to testing, with two exceptions: If the RC-bugginess of the package goes down, it may go in even if it is still RC-buggy. The second exception is if the version of the package in testing is out of sync on the different arches: Then any arch might just upgrade to the version of the source package; however, this can happen only if the package was previously forced through, the arch is in outofsync_arches, or there was no binary package of that arch present in unstable at all during the testing migration.

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

5.14.2.5. Подробности

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

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

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

If you want to see more details, you can look it up on https://release.debian.org/britney/update_output/.

The hints are available via https://release.debian.org/britney/hints/, where you can find the description as well. With the hints, the Debian Release team can block or unblock packages, ease or force packages into testing, remove packages from testing, approve uploads to Прямые обновления тестируемого выпуска or override the urgency.

5.14.3. Прямые обновления тестируемого выпуска

Тестируемый выпуск получает пакеты из нестабильного выпуска в соответствии с описанными ранее правилами. Тем не менее, в некоторых случаях необходимо загружать пакеты, собранные только для тестируемого выпуска. Для этого вы можете использовать загрузку в 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 debian-devel-announce@lists.debian.org.

You should not upload to testing-proposed-updates when you can update your packages through unstable. If you can't (for example because you have a newer development version in unstable), you may use this facility. Even if a package is frozen, updates through unstable are possible, if the upload via unstable does not pull in any new dependencies.

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

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

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

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

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

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

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

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

• Ask for authorization for uploading from the release managers.

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

5.14.4. Часто задаваемые вопросы

5.14.4.1. Что такое критичные для выпуска ошибки, как производится их подсчёт?

Все ошибки, имеющие высокую важность, по умолчанию считаются критичными для выпуска; в настоящее время это ошибки с важностью critical, grave и serious.

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

The unstable bug count comprises all release-critical bugs that are marked to apply to package/version combinations available in unstable for a release architecture. The testing bug count is defined analogously.

5.14.4.2. Как установка какого-то пакета в тестируемый выпуск может сломать другие пакеты?

Структура архивов выпусков такова, что они могут содержать только одну версию пакета; пакет определяется его именем. Поэтому, когда пакет с исходным кодом 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.

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

[1]

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

[2]

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

[3]

ITS is shorthand for "Intend to Salvage"

[4]

Though, if a package still is in the upload queue and hasn't been moved to Incoming yet, it can be removed. (see Загрузка на ftp-master)

5.15. The Stable backports archive

5.15.1. Основы

Once a package reaches the testing distribution, it is possible for anyone with upload rights in Debian (see below about this) to build and upload a backport of that package to stable-backports, to allow easy installation of the version from testing onto a system that is tracking the stable distribution.

One should not upload a version of a package to stable-backports until the matching version has already reached the testing archive.

5.15.2. Exception to the testing-first rule

The only exception to the above rule, is when there's an important security fix that deserves a quick upload: in such a case, there is no need to delay an upload of the security fix to the stable-backports archive. However, it is strongly advised that the package is first fixed in unstable before uploading a fix to the stable-backports archive.

5.15.3. Who can maintain packages in the stable-backports archive?

It is not necessarily up to the original package maintainer to maintain the stable-backports version of the package. Anyone can do it, and one doesn't even need approval from the original maintainer to do so. It is however good practice to first get in touch with the original maintainer of the package before attempting to start the maintenance of a package in stable-backports. The maintainer can, if they wish, decide to maintain the backport themselves, or help you doing so. It is not uncommon, for example, to apply a patch to the unstable version of a package, to facilitate its backporting.

5.15.4. When can one start uploading to stable-backports?

The new stable-backports is created before the freeze of the next stable suite. However, it is not allowed to upload there until the very end of the freeze cycle. The stable-backports archive is usually opened a few weeks before the final release of the next stable suite, but it doesn't make sense to upload until the release has actually happened.

5.15.5. How long must a package be maintained when uploaded to stable-backports?

The stable-backports archive is maintained for bugs and security issues during the whole life-cycle of the Debian stable suite. Therefore, an upload to stable-backports, implies a willingness to maintain the backported package for the duration of the stable suite, which can be expected to be about 3 years from its initial release.

The person uploading to backports is also supposed to maintain the backported packages for security during the lifetime of stable.

It is to be noted that the stable-backports isn't part of the LTS or ELTS effort. The stable-backports FTP masters will close the stable-backports repositories for uploads once stable reaches end-of-life (ie: when stable becomes maintained by the LTS team only). Therefore there won't be any maintenance of packages from stable-backports after the official end of life of the stable suite, as uploads will not be accepted.

5.15.6. How often shall one upload to stable-backports?

The packages in backports are supposed to follow the developments that are happening in Testing. Therefore, it is expected that any significant update in testing should trigger an upload into stable-backports, until the new stable is released. However, please do not backport minor version changes without user visible changes or bugfixes.

5.15.7. How can one learn more about backporting?

You can learn more about how to contribute directly on the backport web site.

It is also recommended to read the Frequently Asked Questions (FAQ).