Содержание
Данная глава содержит информацию, связанную с созданием, загрузкой, сопровождением и переносом пакетов.
Если вы хотите создать новый пакет для дистрибутива Debian, вам следует вначале проверить список требующих доработки и будущих пакетов (WNPP). Проверка списка WNPP гарантирует, что в настоящий момент никто не работает над созданием пакетов для данного ПО, и что не будет проделана повторная работа. Прочтите страницу WNPP для получения дополнительной информации.
Допустим, что более никто не работает над вашим будущим пакетом. Далее, вам
следует отправить сообщение об ошибке (раздел 7.1, «Отправка отчётов об ошибках») в псевдопакете wnpp
с объяснением вашего плана по созданию
нового пакета, ваше сообщение должно в себя включать описание пакета,
лицензию будущего пакета и текущий адрес, по которому этот пакет может быть
загружен.
Тема сообщения об ошибке должна иметь вид ITP:
, подставьте имя нового пакета вместо
foo
-- краткое
описание
foo
. Важность сообщения об ошибке должна быть
установлена в значение wishlist
. Отправьте копию по
адресу <debian-devel@lists.debian.org>
, используя заголовок X-Debbugs-CC (не
используйте CC:, так как в этом случае в теме сообщения не будет указан
номер ошибки). Если вы создаёте много новых пакетов (>10), то помните, что
отправка в список рассылки большого количества отдельных сообщений будет
слишком мешать другим, отправьте сообщение с обзором вашей работы в список
рассылки debian-devel после заполнения всех сообщений об ошибках. Это
позволит сообщить вам другим разработчикам о готовящихся пакетах и позволит
вам проверить ваши описания и имена пакетов.
Добавьте запись вида Closes:
#
в журнал изменений нового пакета
для того, чтобы ваше сообщение об ошибке было автоматически закрыто сразу же
как только пакет будет установлен в архиве (см. раздел 5.8.4, «Когда ошибки исправляются путём новых загрузок»).
nnnnn
Если вы считаете, что по поводу вашего пакета необходимо дать дополнительные
объяснения администраторам очереди новых (NEW) пакетов, добавьте их в журнал
изменений, отправьте по адресу <ftpmaster@debian.org>
ваш ответ на сообщение
электронной почты, которое вы получите как сопровождающий после вашей
загрузки пакета, либо ответьте на сообщение об отказе, если вы осуществляете
загрузку повторно.
Закрывая сообщения об ошибках безопасности, добавляйте номера CVE, а также
Closes: #
. Это помогает
команде безопасности отслеживать уязвимости. Если загрузка осуществляется
для того, чтобы исправить ошибку, и если идентификационный номер
рекомендации по безопасности ещё не известен, советуем вам во время
следующей загрузки изменить запись в журнале изменений и добавить номер
рекомендации. Даже в этом случае добавляйте все доступные указатели на
общую информацию из записи оригинального журнала изменений.
nnnnn
Имеется ряд причин, почему мы просим сопровождающих анонсировать их намерения, они приведены ниже:
Это помогает (потенциальному) сопровождающему получить советы опытных людей, участвующих в списке рассылки, и позволяет этим людям узнать, работает ли уже кто-нибудь над созданием пакета для данного ПО.
Это позволяет другим людям, которые думают о работе над созданием пакета, знать, что кто-то уже начал этим заниматься, и поэтому можно объединить усилия.
Это позволяет остальным сопровождающим знать о данном пакете больше, чем то,
что содержится в одной строке описания и обычной записи из журнала изменений
вида „Initial release“, которые публикуются в <debian-devel-changes@lists.debian.org>
.
Это помогает людям, которые постоянно пользуются
нестабильным
выпуском (и являются теми, кто первый широко
тестирует пакеты). Нам следует поощрять этих людей.
Анонсы дают сопровождающим и другим заинтересованным сторонам лучшее понимание того, что происходит и что является новым в Проекте.
Наиболее частые причины для отказа в добавлении нового пакета см. по адресу https://ftp-master.debian.org/REJECT-FAQ.html.
Изменения, которые вы произвели в пакете, должны быть записаны в файл
debian/changelog
. Эти изменения должны содержать
точное описание того, что было изменено, почему это было изменено (в случае
если имеются какие-либо сомнения), а также номера закрываемых сообщений об
ошибках. Кроме того, в журнале должно быть указано, когда была завершена
работа над пакетом. Этот файл будет установлен как
/usr/share/doc/
,
либо как
пакет
/changelog.Debian.gz/usr/share/doc/
в случае, если пакет является родным.
пакет
/changelog.gz
Файл debian/changelog
соответствует определённой
структуре, имеющей ряд различных полей. Одно из этих полей,
выпуск
, описывается в разделе 5.5, «Выбор выпуска». Дополнительная
информация о структуре этого файла может быть найдена в Политике Debian, в
разделе с названием debian/changelog
.
Записи журнала изменений могут использоваться для автоматического закрытия сообщений об ошибках Debian, когда пакет устанавливается в архив. См. раздел 5.8.4, «Когда ошибки исправляются путём новых загрузок».
Обычная запись в журнале изменений какого-либо пакета, содержащего новую версию из основной ветки разработки ПО, выглядит следующим образом:
* New upstream release.
Имеются специальные инструменты, которые помогают вам создавать записи
журнала изменений и готовить файл changelog
к выпуску —
см. раздел A.6.1, «devscripts
» и раздел A.6.5, «dpkg-dev-el
».
Также см. раздел 6.3, «Лучшие практики для debian/changelog
».
До того как вы загрузите ваш пакет, вам следует провести его простое тестирование. Как минимум вам следует попытаться выполнить следующие действия (вам будет нужна более старая версия того же пакета Debian):
Установите пакет и убедитесь, что ПО работает, либо обновите пакет с более старой версии до вашей новой версии, если пакет Debian для данного ПО уже существует.
Выполните lintian, в качестве цели укажите ваш пакет. Вы
можете запустить lintian следующим образом:
lintian -v
. Эта команда
проверит пакет с исходным кодом, наряду с двоичным пакетом. Если вы не
понимаете вывод, предоставляемый вам lintian, попробуйте
добавить опцию версия-пакета
.changes-i
, это приведёт к тому, что
lintian будет выводить довольно подробное описание
проблему.
Обычно пакет не следует загружать в случае, если
lintian сообщает об ошибках (они начинаются с
E
).
Для получения дополнительной информации о команде
lintian, см. раздел A.2.1, «lintian
».
Также вы можете выполнить debdiff (см. раздел A.2.2, «debdiff»), чтобы проанализировать изменения по сравнению с более старой версией (если таковая существует).
Установите предыдущую версию пакета (если она существует) поверх новой — это
позволит проверить работу сценариев postrm
и
prerm
.
Удалите пакет, затем заново установите его.
Скопируйте пакет с исходным кодом в другой каталог и попытайтесь распаковать
и собрать его заново. Это позволит проверить то, зависит ли пакет от
существующих файлов, которые не были добавлены в сам пакет, а также
проверить то, зависит ли он от того, сохраняются ли права доступа в файлах
из файла .diff.gz
.
Имеется два типа пакетов 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
. Остаток настоящего раздела
посвящён исключительно неродным пакетам.
Во время первой загрузки пакета, версия пакета должна соответствовать
определённой версии основной ветки разработки, должен быть загружен
оригинальный исходный tar-файл, также он должен быть добавлен в файле
.changes
. В последующем этот самый tar-файл должен
использоваться для сборки новых различий (diffs) и файлов
.dsc
, его не нужно будет загружать заново.
По умолчанию команды dpkg-genchanges и
dpkg-buildpackage включат оригинальный исходный tar-файл
тогда и только тогда, когда текущая запись в журнале изменений содержит
версию из основной ветки разработки, которая отличается от предыдущей
записи. Это поведение может быть изменено при помощи использования
-sa
, что позволяет всегда включать оригинальный исходный
tar-файл, либо -sd
, что позволяет всегда игнорировать
его.
Если оригинальный исходный код не включён в загрузку, оригинальный tar-файлс
исходным кодом, используемый dpkg-source при создании
файла .dsc
и diff для загрузки
должен побайтно совпадать с тем файлом, который уже
добавлен в архив.
Заметьте, что в неродных пакетах права доступа к файлам, которые не входят в
*.orig.tar.{gz,bz2,xz}
не будут сохранены, поскольку
diff не сохраняет права доступа к файлам в заплате. Тем не менее, если
используется формат исходного кода “3.0 (quilt)”, права доступа к файлам
внутри каталог debian
сохраняются, так как они
сохранены в архиве tar.
Каждая загрузка должна содержать явное указание того, для какого выпуска
предназначается данный пакет. Процесс сборки пакета извлекает эту
информацию из первой строки файла debian/changelog
и
помещает её в поле Distribution
файла
.changes
.
Обычно пакеты загружаются в нестабильный
выпуск. Загрузки
в нестабильный
(unstable
) или
экспериментальный
(experimental
)
выпуски должны использовать эти названия выпуска в записях журнала
изменений; uploads for other supported suites should use the suite
codenames, as they avoid any ambiguity.
Фактически, существуют и другие выпуски:
кодовое-имя
-security
, прочтите
раздел 5.8.5, «Работа с ошибками, связанными с безопасностью» для получения дополнительной информации.
Нельзя загрузить пакет в несколько выпусков одновременно.
Загрузка в stable
означает, что пакет будет передан в
очередь proposed-updates-new
для проверки управляющими
стабильного выпуска, и если пакеты будут одобрены, то они будут установлены
в каталог stable-proposed-updates
архива Debian.
Отсюда, в свою очередь, пакеты будут перенесены в stable
во время формирования следующей редакции выпуска.
To ensure that your upload will be accepted, you should discuss the changes
with the stable release team before you upload. For that, file a bug against
the release.debian.org
pseudo-package using reportbug, including the patch you
want to apply to the package version currently in
stable
. The patch should be a source
debdiff (see Раздел A.2.2, «debdiff») against the
current version in stable
. The changelog entry should be
against the stable
distribution
(e.g. `jessie') and should be detailed, including
Closes
statements for bugs that are fixed by the upload.
Необходимо с особым вниманием относиться к загрузке пакета в
стабильный
выпуск. По сути, пакет следует загружать в
стабильный
выпуск исключительно в случае, если произошло
что-либо из ниже следующего:
действительно критическая проблема функциональности
пакет больше нельзя установить
пакет отсутствует в выпущенной архитектуре
В прошлом загрузки в stable
использовались и для решения
проблема безопасности. Тем не менее, в настоящее время эта практика
считается устаревшей, поскольку загрузки, используемые для рекомендаций
Debian по безопасности, автоматически копируются в соответствующий архив
proposed-updates
в момент выпуска рекомендации.
См. раздел 5.8.5, «Работа с ошибками, связанными с безопасностью» для получения подробной информации о работе с проблемами
безопасности. Если команда безопасности считает, что проблема не настолько
велика, чтобы исправлять её через механизм DSA
, обычно
управляющие стабильным выпуском добавляют ваше исправление в обычную
загрузку в стабильный
выпуск.
Изменение в пакете чего-либо ещё, что не является действительно важным, крайне не рекомендуется, поскольку даже тривиальные исправления могут вызвать появление новых ошибок.
Пакеты, загружаемые в стабильный
выпуск, должны быть
скомпилированы на системах, работающих под управлением
стабильного
выпуска, чтобы их зависимости были ограничены
библиотеками (а также другими пакетами), доступными в
стабильном
выпуске; например, пакет, загруженный в
стабильный
выпуск, будет отклонён в том случае, если она
зависит от пакета с библиотекой, который доступен только в
нестабильном
выпуске. Крайне не рекомендуется
производить изменения зависимостей других пакетов (путём создания путаницы с
Provides
или файлами shlibs
),
которые могут привести к тому, что эти другие пакеты нельзя будет
установить.
Загрузки в предыдущие стабильные
выпуски возможны до тех
пор, пока эти выпуски не будут добавлены в архив. Те же правила применяются
и к стабильным
выпускам.
Подробности см. в разделе тестируемом выпуске.
Чтобы загрузить пакет, вам следует загрузить файлы (включая подписанные
файлы changes и dsc-файл) с помощью анонимного доступа по ftp на
ftp.upload.debian.org
в каталог /pub/UploadQueue/. Для
того, чтобы файлы были обработаны, они должны быть подписаны ключом,
входящим либо в брелок ключей разработчиков Debian, либо в брелок ключей
сопровождающих Debian (см. https://wiki.debian.org/DebianMaintainer).
Заметьте, что вам следует переслать файл changes самым последним. В противном случае ваша загрузка может быть отклонены потому, что ПО для сопровождения архива, осуществляющее грамматический разбор файла changes, посчитает, что не все файлы были загружены.
Для загрузки пакетов Вам могут пригодиться пакеты dupload или dput.Эти удобные программы помогают автоматизировать процесс загрузки пакетов в Debian.
Для удаления пакетов см. ftp://ftp.upload.debian.org/pub/UploadQueue/README и пакет dcut.
Иногда полезно загрузить пакет сразу же, но так, чтобы этот пакет поступил в архив лишь несколько дней спустя. Например, при подготовке загрузки тем, кто не является сопровождающим, вы возможно захотите дать сопровождающему несколько дней для того, чтобы тот как-то отреагировал.
Загрузка в каталог задержанных пакетов приводит к сохранению пакета в очереди отложенной
загрузки. Когда указанное время ожидания истечёт, пакет будет
перемещён в обычный каталог входящих пакетов для его обработки. Это
производится путём автоматической загрузки на
ftp.upload.debian.org
в каталог загрузки
DELAYED/
(X
-dayX
может быть в интервале от 0 до 15). 0-дней
загружается несколько раз в день на ftp.upload.debian.org
.
Работая с dput, вы можете использовать параметр --delayed
, чтобы поместить пакет в одну
из очередей.
ЗАДЕРЖКА
НЕ загружайте пакет в очередь загрузки
безопасности (на security-master.debian.org
) без
предварительного разрешения от команды безопасности. Если пакет не
соответствует требованиям команды безопасности, он может вызвать множество
проблем и задержек во время рассмотрения этой нежелательной загрузки.
Подробности см. в разделе 5.8.5, «Работа с ошибками, связанными с безопасностью».
В Европе имеется альтернативная очередь загрузки по адресу ftp://ftp.eu.upload.debian.org/pub/UploadQueue/. Она работает точно так же
как и ftp.upload.debian.org
, но для разработчиков из Европы
она может быть более удобной из-за более быстрого доступа.
Кроме того, пакеты можно загружать через ssh на
ssh.upload.debian.org
; файлы должны быть помещены в
/srv/upload.debian.org/UploadQueue
. Эта очередь не
поддерживает отложенные загрузки.
Сопровождающие архива Debian ответственны за обработку загрузок пакетов. По
большей части загрузки обрабатываются автоматически и ежедневно при помощи
специальных инструментов для сопровождения архива, dak
process-upload. Говоря более конкретно, обновление существующих
пакетов, предназначенные для нестабильного
выпуска,
обрабатываются автоматически. В других случаях (особенно это касается новых
пакетов) помещение загруженного пакета в выпуск осуществляется вручную. Если
загрузки обрабатываются вручную, изменение архива может потребовать
некоторого времени. Пожалуйста, будьте терпеливы.
В любом случае вы получите уведомление по электронной почте о том, что пакет был добавлен в архив, в этом уведомлении также указаны сообщения об ошибках, которые будут закрыты благодаря данной загрузке. Внимательно изучите это уведомление, проверьте, все ли сообщения об ошибках, которые должны быть закрыты, в нём указаны.
Уведомление об установке также включает в себя информацию о том, в какой раздел был добавлен ваш пакет. Если имеет место несоответствие, то вы получите об этом отдельное сообщение. Читайте ниже.
Заметьте, что если вы загрузили пакет через очереди, служба очередей также отправит вам уведомление по электронной почте.
Also note that new uploads are announced on the IRC channel
#debian-devel-changes
. If your upload fails silently, it
could be that your package is improperly signed, in which case you can find
more explanations on
ssh.debian.org:/srv/upload.debian.org/queued/run/log
.
Поля Section
и Priority
файла
debian/control
фактически не определяют то, куда в
архиве будет помещён ваш пакет, также они не определяют приоритет. Для
того, чтобы сохранить общую целостность архива, сопровождающие архива
осуществляют контроль над данными полями. Значения в файле
debian/control
в действительности являются лишь
подсказками.
Сопровождающие архива отслеживаю канонические разделы и приоритеты пакетов с
помощью специального файла замещения
. Если между
файлом замещения
и полями пакета, определёнными в файле
debian/control
, имеет место несоответствие, то вы
получите сообщение о расхождении в момент, когда пакет будет установлен в
архив. Вы можете либо исправить ваш файл
debian/control
во время следующей загрузки, либо вы
можете захотеть изменить файл замещения
.
Чтобы изменить раздел, в который был помещён пакет, вам для начала нужно
убедиться, что файл debian/control
в вашем пакете
правилен. Далее, отправьте сообщение об ошибке в ftp.debian.org
с запросом изменения раздела или
приоритета для вашего пакета. Используйте тему сообщения на подобие
override: ПАКЕТ1:раздел/приоритет, [...],
ПАКЕТX:раздел/приоритет
и добавьте обоснование данного изменения в
теле сообщения об ошибке.
Дополнительную информацию о файлах замещения
см. в
dpkg-scanpackages(1) и https://www.debian.org/Bugs/Developer#maintincorrect.
Заметьте, что поле Section
описывает и раздел, и
подраздел, которые описываются в разделе 4.6.1, «Разделы». Если раздел имеет
значение main (основной), то его указание должно быть опущено. Список
разрешённых подразделов может быть найден в https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections.
Каждый разработчик должен быть способен работать с системой отслеживания ошибок Debian. Это предполагает знание того, как следует правильно отправлять сообщения об ошибках (см. раздел 7.1, «Отправка отчётов об ошибках»), как обновлять и упорядочивать их, а также то, как с ними работать и как их закрывать.
Возможности системы отслеживания ошибок описаны в документации по системе отслеживания ошибок для разработчиков. Она включает в себя описание того, как закрывать сообщения об ошибках, отправлять ответные сообщения, назначать важность и теги, отмечать ошибки как перенаправленные, а также многих других вопросов.
Такие операции как переназначение сообщений об ошибках другим пакетам, объединение отдельных сообщений об ошибках в одну проблему, а также повторное открытие ошибок, если они были закрыты прежде времени, осуществляются при помощи так называемого сервера управляющей почты. Все доступные на этом сервере команды описываются в документации по управляющему серверу системы отслеживания ошибок.
Если вы хотите быть хорошим сопровождающим, вам следует периодически
проверять в системе отслеживания ошибок Debian
(BTS) состояние ваших пакетов. Система отслеживания ошибок содержит
все открытые сообщения об ошибках в ваших пакетах. Вы можете проверить их
путём просмотра следующей страницы:
https://bugs.debian.org/
.
ваша-учётная-запись
@debian.org
Сопровождающие взаимодействуют с системой отслеживания ошибок через адреса
электронной почты bugs.debian.org
. Документация по доступным
командам может быть найдена в https://www.debian.org/Bugs/, либо, если вы
установили пакет doc-debian
, вы
можете посмотреть локальные файлы /usr/share/doc/debian/bug-*
.
Некоторые разработчики находят полезным получение периодических отчётов об открытых ошибках. Вы можете добавить работу cron подобно следующей, если вы хотите получить еженедельные сообщения с обзором всех открытых сообщений об ошибках в ваших пакетах:
# запрашивает еженедельные отчёты об ошибках в моих пакетах
0 17 * * fri echo "index maint address
" | mail request@bugs.debian.org
Замените адрес
вашим официальным адресом
сопровождающего Debian.
Отвечая на сообщения об ошибках, убедитесь, что любое обсуждение сообщения
об ошибке отправляется и изначальному автору сообщения об ошибке, и записи в
системе отслеживания ошибок (напр.,
<
). Если вы пишете
новое сообщение и не помните адрес электронной почты изначального автора
сообщения об ошибке, вы можете использовать адрес
123
@bugs.debian.org><
для
того, чтобы связаться с ним и записать вашу почту в
журнал сообщения об ошибке (что означает, что вам не нужно будет отправлять
копию письма на адрес
123
-submitter@bugs.debian.org><
).
123
@bugs.debian.org>
Если вы получили сообщение об ошибке, в котором упоминается FTBFS, то это означает Fails to build from source (не удалось собрать из исходного кода). Те, кто занимаются переносами, часто используют данный акроним.
Как только вы закончили работать с сообщением об ошибке (напр., исправили
ошибку) отметьте его как завершённое
(закройте его),
отправив сообщение с объяснением по адресу
<
. Если вы
исправили ошибку путём изменения и загрузки пакета, вы можете
автоматизировать закрытие сообщения об ошибке как это описано в разделе 5.8.4, «Когда ошибки исправляются путём новых загрузок».
123
-done@bugs.debian.org>
Вам никогда не следует закрывать ошибки через отправку
команды close
для сервера ошибок по адресу
<control@bugs.debian.org>
. Если вы так сделаете, то изначальный автор сообщения
об ошибке не получит какой-либо информации о том, почему сообщение об ошибке
было закрыта.
Как сопровождающий пакетов вы часто будете находить ошибки в других пакетах, иногда вы будете получать сообщения об ошибках в ваших пакетах, которые в действительности касаются ошибок в других пакетах. Возможности системы отслеживания ошибок описываются в документации по системе отслеживания ошибок для разработчиков Debian. Такие операции как переназначение, объединение и отметка тегами сообщений об ошибках описываются в документации по управляющему серверу системы отслеживания ошибок. Данный раздел содержит некоторые рекомендации по управлению сообщениями об ошибках в ваших собственных пакетах, эти рекомендации основываются на коллективном опыте разработчиков Debian.
Отправка сообщений об ошибках по поводу проблем, которые вы найдёте в других пакетах, является одной из гражданских обязанностей сопровождающего, см. раздел 7.1, «Отправка отчётов об ошибках» для получения дополнительной информации. Тем не менее, работа с ошибками в ваших собственных пакетах ещё более важна.
Ниже приведена последовательность шагов, которой можно следовать при работе с сообщением об ошибке:
Решите, соответствует присланный отчёт реальной ошибке или нет. Иногда пользователи всего лишь неправильно запускают программу, поскольку они не прочли документацию. Если вы это обнаружите, то просто закройте сообщение об ошибке, предоставив достаточное количество информации, которая позволит пользователю исправить свою проблему (вышлите ссылки на хорошую документацию и так далее). Если вы снова получите то же сообщение об ошибке, задайте себе вопрос, достаточно ли хороша документация, или может быть программа не может обнаружить случаи неправильного использования и выдать информативное сообщение об ошибке. Об этой проблеме следует сообщить автору основной ветки разработки.
Если тот, кто отправил сообщение об ошибке, не согласен с вашим решением о
закрытии сообщения об ошибке, то он может заново открывать его до тех пор,
пока вы не придёте к согласию о том, что делать. Если вы не сможете найти
общего решения, тогда вы можете отметить ошибку тегом
wontfix
, чтобы люди знали, что ошибка существует, но что
она не будет исправлена. Если эта ситуация не приемлема, вы (или тот, кто
отправил сообщение об ошибке) можете потребовать решение проблемы от
технического комитета, переназначив сообщение об ошибке tech-ctte
(вы можете использовать команду clone,
если вы хотите, чтобы сообщение об ошибке осталось сообщением об ошибке в
вашем пакете). До того, как сделать это, прочтите информацию о рекомендуемой процедуре.
Если ошибка действительно имеет место, но она вызвана другим пакетом, просто
переназначьте сообщение об ошибке тому пакету. Если вы не знаете, какому
пакету следует переназначить сообщение об ошибке, вам следует попросить
помощи в IRC или в
<debian-devel@lists.debian.org>
. Пожалуйста, проинформируйте сопровождающего того
пакета, которому вы переназначаете сообщение об ошибке, например, отправив
копию сообщения для системы отслеживания ошибок, содержащего команды для
переназначения, по адресу
<
,
объясните ему причины в своём сообщении. Заметьте, что простое
переназначение не пересылается сопровождающим пакета,
которому вы переназначаете сообщение об ошибке, поэтому они не будет знать
об этом до тех пор, пока они не посмотрят сводную информацию об ошибках в
своих пакетах.
имя-пакета
@packages.debian.org>
Если ошибка затрагивает работу вашего пакета, вы можете клонировать сообщение об ошибке и переназначить полученную копию тому пакету, который фактически вызывает нежелательное поведение в вашем пакете. В противном случае, ошибка не будет показываться в списке ошибок вашего пакета, что, вероятно, приведёт к тому, что пользователи будут снова и снова сообщать об одной и той же ошибке. Вам следует заблокировать "вашу" ошибку переназначенной, клонированной ошибкой, чтобы засвидетельствовать отношение между ними.
Иногда вам также необходимо изменить важность ошибки так, чтобы она соответствовала вашему определению её важности. Люди обычно склонны преувеличивать важность ошибок для того, чтобы их ошибки были быстрее исправлены. Важность некоторых ошибок может понижена до wishlist, если запрашиваемое изменение является скорее косметическим.
Если ошибка действительно имеет место, но об этой же проблеме было сообщено кем-то ещё, то два релевантных сообщения должны быть объединены в одно с помощью команды merge. В этом случае если ошибка будет исправлена, все те, кто сообщил о ней, будут уведомлены об этом. (Тем не менее, заметьте, что сообщения, отправленные одному из тех, кто сообщил об ошибке, не будут автоматически перенаправлены остальным пользователям, которые тоже сообщили об ошибке.) Подробности о технической стороне команды merge и родственной ей команды unmerge, см. в документации по управляющему серверу системы отслеживания ошибок.
Пользователь, отправивший сообщение об ошибке, мог забыть предоставить
какую-то информацию, в этом случае вам следует попросить их предоставить
необходимую информацию. Вы можете использовать тег
moreinfo
, чтобы отметить сообщение об ошибке как
требующее предоставления дополнительной информации. Более того, если вы не
можете воспроизвести ошибку, вы можете пометить сообщение об ошибке тегом
unreproducible
. Это будет означать, что если кто-то
может воспроизвести ошибку, то вы просите его предоставить вам
дополнительную информацию о том, как воспроизвести эту ошибку. Через
несколько месяцев, если эта дополнительная информация не была никем
отправлена, сообщение об ошибке может быть закрыто.
Если ошибка касается создания пакета, вам следует её исправить. Если вы не
можете сами исправить её, то отметьте сообщение об ошибке тегом
help
. Кроме того, вы можете попросить о помощи в
<debian-devel@lists.debian.org>
или <debian-qa@lists.debian.org>
. Если это проблема основной
ветки разработки, вам следует переслать сообщение об ошибке автору основной
ветки. Простой пересылки сообщения об ошибке не достаточно, вам следует
проверять каждый выпуск основной ветки на предмет исправления этой ошибки.
Если ошибка была исправлена, вам нужно просто закрыть сообщение об ошибке, в
противном случае вам следует напомнить автору об ошибке. Если у вас имеются
требуемые навыки, вы можете подготовить заплату, исправляющую ошибку и
отправить её автору основной ветки. Убедитесь, что вы отправили заплату в
систему отслеживания ошибок и пометили сообщение об ошибке тегом
patch
.
Если вы исправили ошибку в своей локальной копии пакета, либо если
исправление было загружено в репозиторий системы управления версиями, вы
можете отметить сообщение об ошибке тегом pending
, что
будет означать, что ошибка исправлена, и что сообщение об ошибке будет
закрыто при следующей загрузке (добавьте пункт closes:
в
ваш файл changelog
). Это особенно полезно, когда над
одним и тем же пакетом работает несколько разработчиков.
Как только исправленный пакет будет доступен в архиве, сообщение об ошибке должно быть закрыто с указанием версии, в которой ошибка была исправлена. Это может быть сделано автоматически, см. раздел 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
Мы предпочитаем синтаксис closes:
#
, поскольку он является наиболее
точным, также он проще в плане интеграции с текстом файла
XXX
changelog
. Если не указано обратное с помощью
параметра -v
для dpkg-buildpackage,
будут закрыты только те сообщения об ошибках, которые указаны как закрытые в
самой последней записи журнала изменений (по сути, будут закрыты именно те
сообщения об ошибках, которые указаны в файле в разделе об изменениях в
файле .changes
).
Исторически загрузки определяются как загрузки теми, кто
не является сопровождающим (NMU) отмечались тегом
fixed
, но не закрывались, но эта практика была прекращена
с приходом отслеживания версий. То же самое справедливо и по отношению к
тегу fixed-in-experimental
.
Если вы неправильно введёте номер сообщения об ошибке или забудете указать
этот номер в записи журнала изменений, не стесняйтесь исправить эту ошибку и
её последствия. Чтобы заново открыть ошибочно закрытое сообщение об ошибке,
отправьте команду reopen
на адрес системы управления системы отслеживания ошибок,
XXX
<control@bugs.debian.org>
. Чтобы закрыть любое сообщение об ошибках, указанная в
котором ошибка была исправлена в вашей загрузке, перешлите файл
.changes
на адрес
<
, вместо
XXX
-done@bugs.debian.org>XXX
укажите номер ошибки, также добавьте Version:
YYY
и пустую строку в качестве первых двух строк
тела вашего сообщения, замените YYY
на номер
версии, в которой ошибка была исправлена.
Помните, что закрывать ошибки с помощью журнала изменений, как это описано
выше, не является чем-то обязательным. Если вы просто хотите закрыть
сообщения об ошибках, которые никак не касаются сделанной вами загрузки,
закройте ошибку путём отправки вашего объяснения на адрес
<
. Не закрывайте ошибки в записи журнала изменений
какой-либо версии пакета, если изменения в этой версии пакета не имеют
ничего общего с исправление этой ошибки.
XXX
-done@bugs.debian.org>
Общую информацию о том, как писать журнал изменений, см. в разделе 6.3, «Лучшие практики для debian/changelog
».
Из-за того, что ошибки, связанные с безопасностью, обладают скорее некоторой
чувствительной природой, с ними следует работать очень внимательно. Команда
безопасности 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.4, «Подготовка пакетов для решения проблем безопасности»)
Любая помощь, которую вы можете предоставить в плане тестирования (уязвимость, тестирование регрессий и т. д.)
Любая информация, необходимая для рекомендации по безопасности (см. раздел 5.8.5.3, «Рекомендации по безопасности»)
Как сопровождающий пакетов вы ответственны за сопровождение своих пакетов даже в стабильном выпуске. Вы имеете лучшие возможности для оценки заплат и тестирования обновлённых пакетов, поэтому, пожалуйста, внимательно изучите приводимую ниже информацию о том, как подготовить пакеты для работы команды безопасности.
Команда безопасности сопровождает центральную базу данных, систему отслеживания безопасности Debian. Она содержит всю публично доступную информацию о том, что известно о проблемах безопасности: какие пакеты и версии подвержены проблемами, либо были исправлены, а также какие выпуски, стабильный, тестируемый и/или нестабильный, уязвимы. Конфиденциальная информация не добавляется в эту систему.
Вы можете производить поиск по конкретной проблеме или имени пакета. Посмотрите ваш пакет, чтобы узнать, какие проблемы всё ещё открыты. Если вы можете, предоставьте дополнительную информацию об этих проблемах, либо помогите решить их в вашем пакете. Все инструкции доступны на страницах системы отслеживания проблем.
В отличии от большей части другой деятельности, которая происходит в Debian, информация о проблемах безопасности иногда держится в секрете в течении некоторого времени. Это позволяет поставщикам ПО координировать раскрытие этой информации, чтобы минимизировать опасность для своих пользователей. Временное закрытие информации об уязвимости зависит от природы проблемы и соответствующего исправления, а также от того, находится ли уже информация об уязвимости в открытом доступе.
Разработчики могут узнать о проблемах безопасности из следующих источников:
они могут найти упоминание проблемы на публичном форуме (списке рассылки, веб-сайте и т. д.)
кто-то отправляет отчёт об ошибке
кто-то информирует через частную почту
В первых двух случаях информация публична, важно подготовить исправление ошибки как можно раньше. Тем не менее, в последнем случае информация об ошибке может не быть публичной. Тогда при работе с проблемой возможны несколько вариантов действий:
Если проблема безопасности не значительна, иногда нет необходимости скрывать информацию об этой проблеме, следует подготовить исправление и выпустить его.
Если проблема относится к серьёзным проблемам, желательно сообщить о ней другим поставщикам и скоординировать выпуск. Команда безопасности постоянно находится на связи с различными организациями и индивидами, и заботится о распространении информации и координации.
Если тот, кто сообщает о проблеме, просит не раскрывать её, то в любом случае такой запрос следует уважать, конечно, это не касается информирования команды безопасности с целью подготовки исправления для стабильного выпуска Debian. При отправка конфиденциальной информации команде безопасности, обязательно упомяните о полученной просьбе.
Заметьте, что если требуется сохранить тайну, то вы не можете загрузить
исправление в нестабильный
выпуск (или куда-либо ещё,
например, в публичный репозиторий системы управления версиями). Запутывания
информации о подробностях изменения не достаточно, поскольку сам код
доступен общественности и может быть (и будет) просмотрен остальными людьми.
Однако имеются две причины выпускать информацию даже в том случае, если было запрошено этого не делать: проблема уже была известна в течении некоторого времени, либо проблема или эксплоит доступны публично.
Команда безопасности для общения по поводу чувствительных вопросов использует закодированную при помощи ключа PGP переписку. Подробности см. в ЧаВО команды безопасности.
Рекомендации по безопасности выпускаются только для текущего стабильного
выпуска, а не для тестируемого
или
нестабильного
выпусков. Рекомендации при их выпуске
отправляются в список рассылки <debian-security-announce@lists.debian.org>
и
размещаются на веб-странице о
безопасности. Рекомендации по безопасности пишутся и публикуются
командной безопасности. Тем не менее, они вовсе не против того, чтобы
сопровождающий предоставил им какую-либо информацию или написал часть
текста. В рекомендации по безопасности должна содержаться следующая
информация:
Описание проблемы и её масштаба, включая следующее:
Тип проблемы (повышение привилегий, отказ в обслуживании и т. д.)
Какие привилегии могут быть получены и кем (если это имеет место)
Как эта уязвимость может использоваться
Может ли она использоваться удалённо, либо локально
Как проблема была исправлена
Эта информация позволяет пользователям оценить угрозу их системам
Номера версий подверженных проблеме пакетов
Номера версий исправленных пакетов
Информация о том, где можно получить обновлённые пакеты (обычно из архива безопасности Debian)
Ссылки на рекомендации по безопасности основной ветки разработки, идентификационные номера CVE и любую другую информацию, полезную для перекрёстного указания уязвимости
Вы можете помочь команде безопасности, если предоставите им исправления пакетов, подходящие для рекомендации по безопасности для стабильного выпуска Debian.
Когда вы производите обновление стабильного выпуска, следует быть осторожным в том, чтобы не изменить поведение системы и не внести новые ошибки. Для того, чтобы сделать это, для исправления ошибки производите как можно более мелкие изменения. Пользователи и администраторы полагаются на строго определённое поведение ПО, поэтому любое изменение может сломать работу чьей-то системы. Это в особенности касается библиотек: убедитесь, что вы не изменили API или ABI, причём не важно, насколько малым было изменение.
Это означает, что переход на новую версию из основной ветки разработке не является хорошим решением. Вместо этого вам следует осуществить обратный перенос релевантных изменений в версию ПО, которая входит в стабильный выпуск Debian. Как правило, сопровождающие основной ветки разработки помогают сделать это, если это необходимо. Если же нет, то вам может помочь команда безопасности Debian.
В некоторых случаях обратный перенос исправления безопасности невозможен, например, когда должно быть изменено или переписано большое количество исходного кода. Если это имеет место, может потребоваться переход на новую версию основной ветки разработки. Тем не менее, это осуществляется только в крайних случаях, вам всегда следует заранее координировать такой переход с командой безопасности.
С этим де связан и другой важный совет: всегда тестируйте ваши изменения. Если у вас имеется эксплоит, попробуйте использовать его и выяснить, работает ли он на изначальном пакете и действительно ли он не работает на исправленном пакете. Также протестируйте другие, обычные действия, поскольку исправление безопасности может поломать даже кажущиеся несвязанными возможности.
Никогда НЕ добавляйте какие-либо изменения в ваш пакет, которые не связаны напрямую с исправлением уязвимости. Это лишь потребует вернуть изменения, это лишь зря потратит время разработчика. Если в вашем пакете имеются другие ошибки, которые вам хотелось бы исправить, подготовьте загрузку в proposed-updates обычным образом уже после того, как будет выпущена рекомендация по безопасности. Механизм обновления безопасности не служит для внесения в ваши пакеты таких изменений, которые в противном случае были бы отвернуты при их загрузке в стабильный выпуск, поэтому, пожалуйста, не пытайтесь этого делать.
Проверьте и протестируйте ваши изменения столько раз, сколько это возможно.
Проверьте отличия от предыдущей версии (для этого очень полезны
interdiff из пакета patchutils
и debdiff из
пакета devscripts
, см. раздел A.2.2, «debdiff»).
Убедитесь, что вы проверили следующее:
Укажите верный выпуск в вашем файле
debian/changelog
:
кодовое-имя
-security
(напр.,
jessie-security
). Не указывайте
выпуск
-proposed-updates
или
stable
!
Загрузка должна иметь urgency=high.
Ваши записи в журнале изменений должны быть информативны и осмысленны.
Другие пользователи будут полагаться не них при определении того, была
исправлена определённая ошибка или нет. Добавляйте записи
closes:
о любых ошибках
Debian. Всегда добавляйте внешнюю ссылку, желательно идентификатор CVE. Тем не менее, если идентификатор
CVE ещё не был назначен, не ждите его, продолжайте процесс. Указать
идентификатор можно позже.
Убедитесь, что номер версии верен. Он
должен быть больше, чем номер версии текущего пакета, но меньше, чем версии
пакетов в более поздних выпусках. Если вы сомневаетесь относительно версии,
проверьте её с помощью dpkg --compare-versions
. Будьте
внимательны, не используйте повторно номер версии, который вы использовали
для предыдущей загрузки, либо номер, конфликтующий с binNMU. Принято
добавлять к номеру версии
+deb
X
u1
(где X
представляет собой главный номер выпуска),
напр., 1:2.4.3-4+deb8u1
, для последующей
загрузки версию, конечно же, следует увеличить на 1.
Если исходный код из основной ветки разработки не был ранее загружен на
security.debian.org
(во время предыдущего обновления
безопасности), соберите свою загрузку с полным
исходным кодом из основной ветки разработки
(dpkg-buildpackage -sa
). Если же ранее была произведена
загрузка на security.debian.org
, содержащая ту же самую
версию из основной ветки разработки, вы можете осуществить загрузку без
добавления исходного кода из основной ветки (dpkg-buildpackage
-sd
).
Убедитесь, что используется в точности тот же файл
*.orig.tar.{gz,bz2,xz}
, который
использовался в обычном архиве, в противном случае переместить исправление
безопасности в основной архив будет нельзя.
Соберите пакет в чистой системе, в
которой установлен пакеты только из того выпуска, для которого вы собираете
свой пакет. Если у вам нет такой системы, вы можете использовать машину
debian.org (см. раздел 4.4, «Машины Debian»), либо настроить chroot (см. раздел A.4.3, «pbuilder
» и раздел A.4.2, «debootstrap
»).
Никогда НЕ загружайте пакет в очередь
обновлений безопасности (на security-master.debian.org
)
без соответствующего разрешения от команды безопасности. Если пакет не
соответствует требованиями команды безопасности, работа с нежелательной
загрузкой приведёт к возникновению множества проблем и задержек.
Никогда НЕ загружайте ваше исправление в
proposed-updates
, не связавшись с командой безопасности.
Пакеты из security.debian.org
будут скопированы в каталог
proposed-updates
автоматически. Если какой-то пакет с
тем же самым или более высоким номером версии уже установлен в архиве,
обновление безопасности будет отклонено системой, управляющей архивом. В
этом случае стабильный выпуск останется без обновления безопасности.
Как только вы создадите и протестируете новый пакет, когда он будет
утверждён командой безопасности, этот пакет следует загрузить, чтобы он был
установлен в архивы. Для обновлений безопасности пакеты следует загружать
на
ftp://security-master.debian.org/pub/SecurityUploadQueue/
.
Как только будет принята ваша загрузка в очередь обновления безопасности, пакет будет автоматически собран для всех архитектур и сохранён для проверки командой безопасности.
Загрузки, ожидающие принятия или проверки, доступны только членам команды безопасности. Это необходимо потому, что они могут содержать исправления таких проблем безопасности, информация о которых пока не может быть раскрыта.
Если член команды безопасности принимает пакет, этот пакет будет установлен
в security.debian.org
, а также предложен для
соответствующего каталога
выпуск
-proposed-updates
на
ftp-master.debian.org
.
Некоторые действия по управлению архивом в Debian не автоматизированы во время загрузки. Эти процедуры должны быть вручную выполнены сопровождающими. В данной главе содержатся советы о том, что следует делать в этих случаях.
Иногда для какого-то пакета раздел может быть изменён. Например, пакет из
раздела non-free
(раздел несвободных пакетов) может быть
перелицензирован под GPL, в этом случае этот пакет следует переместить в
`main' (основной раздел) или `contrib' (раздел ПО, зависящего от
несвободного ПО).[3]
Если вам нужно изменить раздел у одного из ваших пакетов, измените
управляющую информацию о пакете, затем заново загрузите ваш пакет
(подробности см. в Руководстве по политике
Debian). Вам следует чётко убедиться, что вы добавили
.orig.tar.{gz,bz2,xz}
в вашу загрузку (даже если вы не
загружаете новую версию из основной ветки разработки), либо что этот файл не
будет встречаться в новом разделе с остальной частью пакета. Если ваш новый
раздел верен, пакет будет перемещён автоматически. Если же пакет не будет
перемещён, тогда свяжитесь с управляющими ftp для того, чтобы понять, что же
произошло.
Если, с другой стороны, вам необходимо изменить подраздел
одного из ваших пакетов (напр., „devel“, „admin“), то это уже немного другая
процедура. Исправьте подраздел в управляющем файле вашего пакета, затем
заново загрузите пакет. Кроме того, вам следует обновить файл отклонений,
это описано в разделе 5.7, «Определение раздела для пакета, подраздела и приоритета».
Если по какой-то причине вам необходимо полностью удалить пакет (например,
если он представляет собой устаревшую библиотеку для совместимости, которая
более не требуется), вам необходимо отправить отчёт об ошибке в псевдопакете
ftp.debian.org
с просьбой об
удалении вашего пакета; как и все сообщения об ошибках, это сообщение об
ошибках обычно должно иметь важность normal. Заголовок сообщения об ошибке
должен иметь вид RM:
, где
пакет
[список архитектур]
--
причина
пакет
— это пакет, который следует удалить, а
причина
— краткое описание причины, по которой вы
отправляете запрос на удаление. [список
архитектур]
опционален и и требуется только в том случае, если
пакет необходимо удалить только для некоторых архитектур, а не для
всех. Заметьте, что утилита reportbug создаст заголовок,
соответствующий указанным правилам, если вы будете использовать её для
отправки сообщения об ошибке в псевдопакете ftp.debian.org
.
Если вы хотите удалить сопровождаемый вами пакет, вам следует указать это в
заголовке вашего сообщения об ошибке, добавив в начале
ROM
(Request Of Maintainer, Запрос сопровождающего).
Имеется некоторое количество других стандартных сокращений, используемых при
удалении пакетов, полный список см. на странице https://ftp-master.debian.org/removals.html. Кроме того, на этой
странице представлен удобный обзор обработки запросов об удалении.
Заметьте, что удаления могут быть выполнены только для
нестабильного
, экспериментального
и
стабильного
выпусков. Пакеты из
тестируемого
выпуска напрямую не удаляются. Они будут
удалены автоматически после удаления пакетов из
нестабильного
выпуска, и если в
тестируемом
выпуске от них не зависит ни один
пакет. (Удаления из тестируемого
выпуска возможны при
отправке сообщения об ошибке в псевдопакете release.debian.org
. См. раздел 5.13.2.2, «Удаление из тестируемого выпуска».)
Имеется одно исключение, при котором явный запрос об удалении не требуется: если двоичный пакет или пакет с исходным кодом более не может быть собран из исходного кода, в этом случае он будет удалён в полуавтоматическом режиме. Для двоичного пакета это означает, что у него более не имеется пакета с исходным кодом, который создаёт данный двоичный пакет; если двоичный пакет не создаётся на некоторых архитектурах, запрос об удалении этого пакета всё равно требуется. Для пакета с исходным кодом это означает, что все двоичные пакеты, на которые ссылается этот пакет, были приняты другим пакетом с исходным кодом.
В вашем запросе об удалении вам следует подробно описать причины, обосновывающие ваше требование. Это позволит избежать нежелательных удалений и отследить то, почему пакет был удалён. Например, вы можете указать имя пакета, которые заменяет удаляемый пакет.
Обычно просят удалить те пакеты, которые сопровождаются самим запрашивающим
об удалении. Если вы хотите удалить другой пакет, вам следует получить на
это разрешение от сопровождающего этого пакета. Если пакет должен быть
признан осиротевшим, если он не имеет сопровождающего, то для начала вам
следует обсудить запрос об удалении в <debian-qa@lists.debian.org>
. В случае если было
принято решение об удалении пакета, вам следует переназначить сообщение об
ошибке в пакете wnpp
и изменить его заголовок на
O:
вместо того, чтобы отправлять новое сообщение об
ошибке с запросом об удалении.
Дополнительная информация, связанная с этими вопросами, а также по теме удаления других пакетов может быть найдена по адресу https://wiki.debian.org/ftpmaster_Removals и https://qa.debian.org/howto-remove.html.
Если вы сомневаетесь в том, может ли быть удалён какой-либо пакет,
обратитесь по адресу <debian-devel@lists.debian.org>
с этим вопросом. Кроме того,
интерес представляет программа apt-cache из пакета
apt
. При запуске apt-cache
showpkg
, эта программа отобразит
подробную информацию о пакет
пакете
, включая его
обратные зависимости. Другими полезными программами являются
apt-cache rdepends, apt-rdepends,
build-rdeps (из пакета devscripts
) и grep-dctrl.
Удаление осиротевших пакетов обсуждается в <debian-qa@lists.debian.org>
.
После удаления пакета следует разобраться с его сообщениями об ошибках. Они
должны быть либо переназначены другому пакету в случае, когда фактический
код ПО развился в другой пакет (напр., libfoo12
был
удалён из-за того, что libfoo13
его вытеснил), либо
закрыты если это ПО более не является частью Debian. Закрывая сообщения об
ошибках, не отмечайте их как исправленный в версиях пакета из предыдущих
выпусков Debian, они должны быть отмечены как исправленные в
<наиболее -свежей-версии-в-Debian>+rm
.
Раньше можно было удалять пакеты из каталога incoming
.
Тем не менее, в введением новой системы входящих пакетов это более не
возможно. Вместо этого вам следует загрузить новую версию вашего пакета с
более высоким номером версии, чем имеет тот пакет, который вы хотите
заменить. Обе версии будут установлены в архив, но лишь пакет с более
высокой версией будет фактически доступен в нестабильном
выпуске, поскольку предыдущая версия будет сразу же заменена более новой
версией. Тем не менее, если вы хорошо тестируете ваши пакеты, нужды
заменять пакет скорее всего не возникнет.
Если сопровождающие основной ветки разработки решают изменить название
своего ПО (либо если вы дали вашему пакету неверное имя), вам необходимо
следовать процессу по переименованию пакета, который включает в себя два
шага. На первом шаге измените файл debian/control
так,
чтобы в нём было отражено новое имя пакета, а также для того, чтобы
устаревшее имя пакета было указано для замены, предоставления и в списке
конфликтующих пакетов (см. Руководство по
политике Debian). Заметьте, что вам следует добавлять отношение
Provides
только тогда, когда все пакет, зависящие от
устаревшего пакета, продолжают работать после переименования. Когда вы
загрузите пакет, и он будет перемещён в архив, отправьте сообщение об ошибке
в псевдопакете ftp.debian.org
с
просьбой удалить пакет с устаревшим именем (см. раздел 5.9.2, «Удаление пакетов»).
Не забудьте правильно переназначить сообщения об ошибке, чтобы они отсылали
к новому имени пакета.
Вы можете допустить ошибку при создании вашего пакета, тогда вы захотите
заменить свой пакет. Единственным способом сделать это является увеличение
номера версии и загрузка новой версии пакет. Старая версия как обычно
станет устаревшей. Заметьте, что это касается каждой части вашего пакета,
включая и исходный код: если вы хотите заменить архив tarball с исходным
кодом из основной ветки, вам придётся загрузить ваш пакет с другим номером
версии. Проще всего заменить foo_1.00.orig.tar.gz
на
foo_1.00+0.orig.tar.gz
, либо
foo_1.00.orig.tar.bz2
. Данное ограничение позволяет
каждому файлу на ftp иметь уникальное имя, что помогает гарантировать
согласованность в сети зеркал.
Если вы не можете более сопровождать пакет, вам нужно сообщить об этом
остальным, и убедиться, что ваш пакет отмечен как осиротевший. Вам следует
установить сопровождающего пакета в значение Debian QA Group
<packages@qa.debian.org>
и отправить сообщение об ошибке в псевдопакете
wnpp
. Заголовок сообщения об ошибке
должен иметь вид O:
, что показывает, что
пакет осиротел. Важность сообщения об ошибке должна иметь значение
пакет
--
краткое описание
normal
; если пакет имеет стандартный приоритет или выше,
важность сообщения об ошибке должна иметь значение important. Если вы
считаете это необходимым, отправьте копию сообщения на адрес
<debian-devel@lists.debian.org>
, добавив этот адрес в заголовок X-Debbugs-CC: вашего
сообщения (не используйте CC:, так как тогда тема сообщения не будет
содержать номер сообщения об ошибке).
Если вы хотите отдать пакет, но вы можете пока продолжать сопровождать его,
то вам следует отправить сообщения об ошибке в псевдопакете wnpp
, сообщение должно иметь заголовок вида
RFA:
. пакет
-- краткое
описание
RFA
означает
Request For Adoption
(запрос об усыновлении).
Дополнительная информация доступна на веб-страницах WNPP.
Список пакетов, которым требуются новые сопровождающие, доступен на странице Требующих доработки и будущих пакетов (WNPP). Если вы хотите заняться сопровождением какого-либо пакета из тех, что приведены в списке WNPP, обратитесь к вышеупомянутой странице для получения информации и сведений о процедуре.
Нельзя просто взять и заняться работой над пакетом, который кажется вам заброшенным — это было бы кражей пакета. Вы, конечно, можете связаться с текущим сопровождающим и спросить его об этом. Если у вас имеются основания полагать, что сопровождающий просто отсутствует без уведомления об этом (AWOL, absent without leave), см. раздел 7.4, «Работа с неактивными и/или недоступными сопровождающими».
Как правило, вы не можете заняться работой над пакетом без специального согласия на это от текущего сопровождающего. Даже если он вас игнорирует это всё равно не является основанием для начала работы над пакетом. Жалобы на сопровождающих должны высказываться в списке рассылки для разработчиков. Если дискуссия не заканчивается позитивным заключением, а проблема имеет техническую природу, подумайте над тем, чтобы привлечь к ней внимание технического комитета (дополнительную информацию см. на странице технического комитета).
Если вы занялись работой над старым пакетом, вам вероятно захочется, чтобы в
системе отслеживания ошибок в качестве официального сопровождающего этого
пакета были указаны вы. Это будет сделано автоматически как только вы
загрузите новую версию с обновлённым полем Maintainer
,
хотя на это может потребоваться несколько часов после выполнения загрузки.
Если вы пока не собираетесь загружать новую версию, вы можете использовать
информацию из раздела 4.10, «Система отслеживания пакетов Debian» для получения сообщений об ошибках. Тем не менее,
убедитесь, что старый сопровождающий не против того факта, что он будет
получать сообщения об ошибках в течении какого-то времени.
Пакеты часто удаляются из-за наличия в них критичных для выпуска ошибок, отсутствия сопровождающих, слишком малого числа пользователей или низкого качества. Хотя процесс повторного добавления пакета схож с первоначальной работой над пакетом, вы можете избежать некоторых ловушек, выполнив для начала небольшое историческое исследование.
Для начала вам следует проверить, почему пакет был удалён. Эта информация может быть найдена в сообщении об удалении в разделе новостей на странице системы отслеживания пакетов данного пакета, либо при просмотре журнала удалений. Сообщение об удалении в системе отслеживания ошибок содержит сведения о том, почему пакет был удалён, а также покажет вам то, над чем вам следует поработать для того, чтобы заново добавить пакет. В сообщении может содержаться сведения о том, что вместо повторного добавления пакета лучше всего переключиться на какое-то другое ПО.
Хорошо было бы связаться с предыдущими сопровождающими и выяснить, работают ли они над повторным добавлением пакета, заинтересованы ли они в совместном сопровождении пакета, заинтересованы ли они быть наставником пакета, если это необходимо.
Вам следует сделать всё, что требуется, до того как добавлять новые пакеты (раздел 5.1, «Новые пакеты»).
В качестве основы для своей работы вам следует взять самый последний из
доступных и подходящих пакетов. Это может быть самая последняя версия из
нестабильного
выпуска, которая всё ещё доступна в снимке архива.
Система контроля версий, которая использовалась предыдущим сопровождающим,
может содержать полезные изменения, поэтому проверка репозитория может
оказаться хорошей идеей. Проверьте, содержит ли файл
control
в предыдущем пакете какие-либо заголовки со
ссылками на систему контроля версий для данного пакета, и если да, то
существует ли всё ещё этот репозиторий.
Удаление пакета из нестабильного
выпуска (не из
тестируемого
, стабильного
или
предыдущего стабильного
выпусков) приводит к закрытию
всех сообщений об ошибках, которые связаны с удаляемым пакетом. Вам следует
проверить все закрытые сообщения об ошибках (включая архивированные
сообщения об ошибках), разархивировать и заново открыть любые закрытые
сообщения об ошибках в версии, заканчивающейся на +rm
, и
которые всё ещё актуальны. Любые неактуальные сообщения об ошибках должны
быть помечены как исправленные в той версии, в которой они были исправлены,
если это, конечно, известно.
Debian поддерживает всё увеличивающееся число архитектур. Даже если вы не занимаетесь переносом и используете только одну архитектуру, вы как сопровождающий обязаны знать о проблемах, связанных с переносимостью. Следовательно, даже если вы не занимаетесь переносом, вам следует прочесть большую часть данной главы.
Перенос представляет собой сборку пакетов Debian для архитектур, которые
отличаются от архитектуры для которой сопровождающим был изначально собран
двоичный пакет. Это уникальная и важная работа. В действительности, те,
кто занимаются переносом, выполняют большую часть фактической компиляции
пакетов Debian. Например, когда сопровождающий загружает (переносимые)
пакеты с исходным кодом с двоичными пакетами для архитектуры
i386
, двоичные пакеты будут собраны для каждой из
оставшихся архитектур, что равно 11 сборкам.
У тех, кто занимается переносом, трудная и необычная задача, поскольку им необходимо работать с большим объёмом пакетов. В идеале каждый пакет с исходным кодом должен собираться прямо из коробки. К сожалению, зачастую это не так. Данный раздел содержит список „ошибочек“, которые часть совершают сопровождающие Debian — общих проблем, которые ставят в тупик тех, кто занимается переносом, и делают их работу неоправданно сложной.
В первую очередь (и это самое важное) следует быстро отвечать на сообщения об ошибках или проблемах, которые были присланы теми, кто занимается переносом. Пожалуйста, обращайтесь с этими людьми вежливо, как будто они являются вашими помощниками в работе по сопровождению вашего пакета (а они фактически ими и являются). Будьте терпимы к кратким или даже неясным сообщениям об ошибках; приложите все усилия для того, чтобы выяснить, в чем состоит проблема.
По большей части, почти все проблемы, на которые обращают внимание те, кто занимает переносом, вызваны ошибками, допущенными при создании пакетов, в пакетах с исходным кодом. Ниже приведён список того, что вам следует проверить или о чём нужно всегда помнить.
Убедитесь, что ваши настройки Build-Depends
и
Build-Depends-Indep
в debian/control
выставлены правильно. Лучшим способом проверить это является использование
пакета debootstrap
для создания на
базе нестабильного
выпуска окружения chroot (см. раздел A.4.2, «debootstrap
»).
Внутри окружения chroot установите пакет build-essential
и указанные в
Build-Depends
и/или
Build-Depends-Indep
зависимости вашего пакета. Наконец,
попытайтесь собрать ваш пакет в полученном окружении chroot. Эти шаги могут
быть автоматизированы, если вы будете использовать программу
pbuilder, которая входит в пакет с тем же именем
(см. раздел A.4.3, «pbuilder
»).
Если вы не можете правильно настроить chroot, вам может помочь dpkg-depcheck (см. раздел A.6.6, «dpkg-depcheck»).
Инструкции по настройке сборочных зависимостей см. в Руководстве по политике Debian.
Не указывайте в качестве архитектуры отличное от all
ли
any
значение, если только вы действительно не имеете это
в виду. В большинстве случаев сопровождающие не следуют инструкциям Руководства по политике Debian. Установка
архитектуры в значение только какой-то одной архитектуры (такой как
i386
или amd64
) обычно оказывается
неправильным.
Убедитесь, что ваш пакет с исходным кодом корректен. Выполните
dpkg-source -x
для
того, чтобы убедиться, что ваш пакет с исходным кодом распаковывается
правильно. Далее, попытайтесь собрать ваш пакет с нуля с помощью
dpkg-buildpackage.
пакет
.dsc
Убедитесь, что в вашем пакете с исходным кодом нет файлов
debian/files
или
debian/substvars
. Они должны быть удалены при помощи
цели clean
из debian/rules
.
Убедитесь, что вам не требуются локально установленные или исправленные
настройки или программы. Например, вам никогда не следует вызывать
программы из /usr/local/bin
и других подобных место.
Попытайтесь не использовать программы, которые были настроены каким-то
специальным способом. Попытайтесь собрать ваш пакет на другой машине, даже
если она принадлежит к той же архитектуре.
Не используйте при сборке пакета какие-либо уже установленные пакеты (это более конкретный вариант приведённого выше случая). Конечно, бывают и исключения для этого правила, но помните, что любой подобный случай требует ручного вмешательства и не может быть выполнен автоматическими сборщиками пакетов.
Если это возможно, не используйте компилятор какой-то конкретной версии. Если это невозможно, то убедитесь, что ваши сборочные зависимости отражают это ограничение, хотя вы, вероятно, просите о чём-то проблематичном, поскольку разные архитектуры иногда основываются на разных компиляторах.
Убедитесь, что ваш файл debian/rules
содержит отдельные
цели binary-arch
и binary-indep
, как
то требуется в Руководстве по политике Debian. Убедитесь, что обе цели
работают независимо друг от друга, то есть, что вы можете вызвать одну цель,
не вызывая до этого другой. Для проверки этого, попытайтесь запустить
dpkg-buildpackage -B.
Если пакет собирается из коробки для той архитектуры, на которую он должен быть перенесён, то вам повезло и ваша работа довольно проста. Данный раздел касается этого случая; в разделе описывается то, как собирать и загружать ваш двоичный пакет так, чтобы он был правильно установлен в архив. Если вам требуется внести изменения в пакет для того, чтобы он мог быть скомпилирован для других архитектур, вам будет нужно выполнить NMU пакета с исходным кодом, поэтому обратитесь к разделу 5.11.1, «Когда и как делать NMU».
При загрузке тем, кто занимается переносом, изменения исходного кода не
вносятся. Вам не нужно трогать какие-либо файлы в пакете с исходным кодом.
Это предполагает и файл debian/changelog
.
Можно вызвать dpkg-buildpackage как
dpkg-buildpackage -B
-m
. Конечно, установите
ваш адрес электронной почты в качестве значения поля
porter-email
porter-email
. При использовании цели
binary-arch
в debian/rules
будет
выполнена сборка двоичных пакетов только для зависящих от архитектуры частей
пакета.
Если вы работаете на машине Debian для того, чтобы заниматься переносом, и
вам локально требуется подписать вашу загрузку для того, чтобы она была
принята в архив, вы можете запустить debsign, указав ваш
файл .changes
в целях удобства, файл будет подписан,
либо вы можете использовать удалённый режим подписывания командой
dpkg-sig.
Иногда первоначальная загрузка, связанная с переносом, проблематична из-за того, что окружение, в котором был собран пакет, не было достаточно хорошо (устаревшая или не используемая более библиотека, плохой компилятор и т. д.). Тогда вам может потребоваться заново скомпилировать пакет в обновлённом окружении. Тем не менее, в этом случае вам придётся увеличить номер версии пакета, чтобы старый плохой пакет был заменён на новый в архиве Debian (dak отказывается устанавливать новые пакеты, если номер их версии не больше уже доступных пакетов).
Вам следует убедиться, что ваша двоичная NMU не приведёт к тому, что пакет
перестанет устанавливаться. Это может произойти в случае, если пакет с
исходным кодом порождает зависящие и независящие от архитектуры пакеты,
взаимные зависимости которые созданы подстановкой переменной dpkg
$(Source-Version)
.
Несмотря на необходимое изменение журнала изменений, это называется двоичной NMU — в этом случае нет необходимости делать пакеты других архитектур устаревшими и заново их компилировать.
Для такой повторной компиляции требуется специальное „магическое“ назначение версий, так чтобы инструменты для сопровождения архива распознали, что хотя даже и имеется новая Debian-версия, соответствующего обновления исходного кода не было. Если вы сделаете это неправильно, сопровождающие архива отклонят вашу загрузку (из-за отсутствия соответствующего исходного кода).
„Магия“ для NMU повторной компиляции включается путём использования суффикса
в номере версии пакет, имеющего следующий вид:
b
. Например, если
последняя версия пакета, которую вы заново компилируете, была версией
номер
2.9-3
, ваша двоичная NMU должна иметь версию
2.9-3+b1
. Если последней версией была
3.4+b1
(т. е., родной пакет, для которого в предыдущий
раз уже была выполнена NMU с повторной компиляцией), ваша двоичная NMU
должна иметь номер версии 3.4+b2
.[4]
Подобно первоначальной загрузке, связанной с переносом, правильный вызов
dpkg-buildpackage имеет вид dpkg-buildpackage
-B
, что означает, что будут собраны только зависящие от
архитектуры части пакета.
Те, кто занимаются переносом и выполняют NMU исходного кода, следуют советам из раздела 5.11, «Загрузки не-сопровождающим (NMU)», как и те, кто переносом не занимается. Тем не менее, ожидается, что цикл ожидания для NMU исходного кода, выполненной тем, кто занимается переносом, меньше, чем для того, кто переносом не занимается, поскольку те, кто занимается переносом, должны охватить большое количество пакетов. Опять же, ситуация зависит от того, в какой выпуск они хотят осуществить загрузку. Также важно то, является ли данная архитектура кандидатом на включение в следующий стабильный выпуск; управляющие выпуском решают и сообщают о том, какие архитектуры являются такими кандидатами.
Если вы не занимаетесь переносом и выполняете NMU для
нестабильного
выпуска, вам следует придерживаться
приведённых выше советов по переносу, но с двумя изменениями. Во-первых,
период ожидания принятия — время между тем, когда было сообщено об ошибке в
систему отслеживания ошибок, и тем, когда для NMU наступает подходящее время
— равен семи дням для тех, кто занимается переносом, и работает над
нестабильным
выпуском. Этот период может быть уменьшен
по усмотрению тех, кто занимается переносом, в случае, если проблема
является критической и представляет собой серьёзную трудность для процесса
переноса пакета. (Помните, это не является Политикой, это лишь негласно
принято в сообществе.) Для выполнения загрузки в
стабильный
или тестируемый
выпуски
свяжитесь с соответствующей выпускающей командой.
Во-вторых, те, кто занимается переносом и выполняют NMU исходного кода,
должны убедиться, что сообщение об ошибке, отправленное в систему
отслеживания ошибок, имеет важность serious
или выше.
Это гарантирует, что отдельный пакет с исходным кодом может использоваться
для компиляции пакета для каждой поддерживаемой Debian на момент выпуска
архитектуры. Важно, что у нас имеется одна версия двоичного пакета и пакета
с исходным кодом для всех архитектур для того, чтобы соответствовать
множеству лицензий.
Те, кто занимаются переносом, должны попытаться избежать заплат, которые
просто обходят ошибки в текущей версии окружения компиляции, ядра или
libc. Иногда такие клуджи не могут помочь. Если вам нужно обойти ошибки
компилятора или чего-то подобного, убедитесь, что вы выполнили корректно
#ifdef
для своей работы; также, документируйте ваши
клуджи, чтобы люди знали, как удалить их когда внешние проблемы будут
исправлены.
У тех, кто занимается переносом, также имеется неофициальное место, куда они могут поместить результаты своей работы во время периода ожидания. Это помогает остальным, кто занимается переносом, использовать вашу работу даже во время периода ожидания. Конечно, такие места не являются официальными и не имеют какого-либо специального статуса, поэтому будьте внимательны.
Имеется специальная инфраструктура и некоторые инструменты, необходимые для автоматизации переноса пакетов. Данный раздел сдержит краткий обзор автоматизации и переноса с помощью данных инструментов; дополнительную информацию см. в документации пакетов или по другим ссылкам.
Веб-страницы, содержащие информацию о статусе каждого переноса, можно найти по адресу: https://www.debian.org/ports/.
У каждого переноса Debian имеется свой список рассылки. Список списков рассылки различных проектов по переносу может быть найден по адресу: https://lists.debian.org/ports.html. Эти списки рассылки используются для координации работы и связи пользователей с теми, кто работает над переносом.
Описания некоторых инструментов переноса могут быть найдены в разделе A.7, «Инструменты для переноса».
Система wanna-build
используется как
распределённая клиент-серверная система сборки дистрибутива. Обычно она
используется вместе со сборочными службами, запускающими программу
buildd
. Сборочные
службы
являются „подчинёнными“ узлами, они связываются с
центральной системой wanna-build
для
получения списка пакетов, которые следует собрать.
Система wanna-build
пока недоступна
в виде пакета; тем не менее, она используется для переноса Debian в режиме
автоматической сборки пакетов. Инструмент, используемый для создания
фактических сборок пакетов, sbuild
,
доступен в виде пакета, см. его описание в разделе A.4.4, «sbuild
». Заметьте, что версия в
пакете отличается от той, что используется в сборочных службах, но она
достаточно близка к ней и поэтому подходит для воспроизведения проблем.
Большая часть данных, создаваемых системой wanna-build
, которая обычно бывает полезна для
тех, кто занимается переносом, доступна на следующей веб-странице: https://buildd.debian.org/. Эта информация включает в себя обновляемую
каждую ночь статистику, информацию об очереди и журналы попыток сборки.
Мы очень гордимся этой системой, поскольку у неё так много возможных пользователей. Независимые от разработки группы могут использовать данную систему для подготовки различных вариантов Debian, которые иногда могут быть интересы и более широкому кругу пользователей (например, вариант Debian, собранный с поддержкой проверки связывания средствами gcc). Кроме того, она позволяет довольно быстро заново собрать целый выпуск Debian.
Связаться с командой wanna-build, ответственной за службы buildd, можно по
адресу: debian-wb-team@lists.debian.org
. Для того, чтобы
определить, с кем (команда wanna-build, команда выпуска) и как (почта,
система отслеживания ошибок) следует связаться в конкретном случае,
см. https://lists.debian.org/debian-project/2009/03/msg00096.html.
При запросе binNMU или возвратов (повторов после неудачной сборки) используйте описанный в https://release.debian.org/wanna-build.txt формат.
Некоторые пакеты всё равно имеют проблемы со сборкой и/или с работой на
некоторых поддерживаемых Debian архитектурах, они вообще не могут быть
перенесены, либо для их переноса требуется слишком много времени. Примером
этого является пакет, который конкретно связан с SVGA (доступен только для
i386
и amd64
), либо использует другие
специфические возможности оборудования, которые совсем не поддерживаются на
всех архитектурах.
Для того, чтобы сломанные пакеты не были загружены в архив и не потратили зря время работы buildd, вам следует выполнить несколько вещей:
Во-первых, убедитесь, что ваш пакет действительно не может быть собран на архитектурах, которые он не может поддерживать. Для достижения этого имеется несколько способов. Предпочтительный способ состоит в том, чтобы иметь небольшой тестовый набор для использования во время сборки, который будет проверять функциональность пакета и который будет завершаться неудачей в случае, если пакет не работает. Отличной идеей является и то, что это помешает (некоторым) сломанным загрузкам на все архитектуры, а также позволит пакету собираться сразу как только требуемая функциональность будет доступна.
Кроме того, если вы убеждены, что список поддерживаемых архитектур вполне
постоянен, вам следует изменить any
на список
поддерживаемых архитектур в debian/control
. При этом
способе сборка опять же завершиться неудачно, пользователю будет сообщено об
этом, даже хотя попытки сборки не было.
Для того, чтобы ПО для автоматической сборки не пыталось без необходимости
на то собрать ваш пакет, в Packages-arch-specific
должен быть включён список, используемый сценарием
wanna-build. Текущая версия доступна как https://anonscm.debian.org/cgit/mirror/packages-arch-specific.git/tree/Packages-arch-specific; с кем можно связаться по поводу изменений см. в
начале файла.
Заметьте, что это недостаточно просто добавить ваш пакет в
Packages-arch-specific
без того, чтобы его сборка на
неподдерживаемых архитектурах завершилась неудачно: тот, кто занимается
переносом, либо кто-либо другой, пытающиеся собрать ваш пакет, может
случайно загрузить его, не заметив, что пакет не работает. Если в прошлом
некоторые двоичные пакеты были загружены и для неподдерживаемых архитектур,
запросите их удаление, заполнив сообщение об ошибке в ftp.debian.org
.
По умолчанию пакеты из раздела non-free
не собираются
сетью автоматической сборки (по большей части из-за того, что это может быть
запрещено лицензией пакета). Чтобы разрешить сборку пакета, вам следует
предпринять следующие шаги:
Проверьте, законно ли и возможно ли технически автоматически собирать данный пакет;
Добавьте XS-Autobuild: yes
в заголовок файла
debian/control
;
Отправьте сообщение по электронной почте на адрес <nonfree@release.debian.org>
,
объясните, почему пакет можно собрать как с правовой, так и с технической
точки зрения с помощью автоматической сборки.
Каждый пакет имеет одного или нескольких сопровождающих. Обычно это люди, которые работают над пакетом и выполняют загрузки новых версий. В некоторых ситуациях бывает полезно, если и другие разработчики смогут загрузить новую версию, например, если они хотят исправить ошибку в пакете, сопровождением которого они не занимаются, и если сопровождающий нуждается в помощи для решения проблем с пакетом. Такие загрузки называются загрузки не-сопровождающими, Non-Maintainer Uploads (NMU).
До выполнения NMU, ответьте на следующие вопросы:
Предприняли ли вы NMU для того, чтобы помочь сопровождающему? Поскольку по поводу того, требуется ли сопровождающему помощь, могут возникнуть споры, существует очередь DELAYED, загрузка в которую позволяет сопровождающему отреагировать на вашу загрузку, а также позволяет другим оценить вклад вашей NMU-загрузки.
Исправляет ли ваша NMU-загрузка ошибки? (Под "ошибками" подразумеваются любые ошибки, напр. пожелания по созданию пакета для версии из основной ветки разработки, но следует постараться минимизировать проблема сопровождающего.) Исправление косметических проблем или изменение стиля создания пакета (напр., переход с cdbs на dh) в NMU не желательны.
Даёте ли вы достаточное количество времени сопровождающему? Когда в системе отслеживания ошибок было прислано сообщение об ошибке? Человек может быть занят одну или две недели, в этом не ничего необычного. Так ли серьёзная ошибка, что её необходимо исправить прямо сейчас, можно ли подождать ещё несколько дней?
Насколько вы уверены в своих изменениях? Помните клятву Гиппократа: "Не навреди." Лучше оставить пакет даже с самой серьёзной ошибкой, чем применять к нему неработающую заплату, либо заплату, которая скорее скрывает ошибку, а не решает её. Если вы не уверены на 100% в том, что вы делаете, лучше будет попросить совета у других. Помните, что если вы что-то сломаете во время NMU, многие люди будут недовольны.
Выразили ли вы ясно ваше намерение сделать NMU, по меньшей мере в системе отслеживания ошибок? Если вы не получили какого-либо ответа, то попытайтесь связаться с сопровождающим другими способами (напишите сообщение на адрес электронной почты сопровождающего, на его частный адрес электронной почты, через IRC).
Если сопровождающий обычно активен и отзывчив, попытались ли вы с ним связаться? Вообще же предпочтительно, чтобы сопровождающие самостоятельно решали проблемы в своих пакетах, нужно дать им возможность проверить вашу заплату и при необходимости исправить её, поскольку они скорее всего лучше осведомлены о потенциальных проблемах, которые могут быть упущены в ходе NMU. Часто время каждого используется значительно лучше, если у сопровождающего будет возможность самому загрузить исправление.
Если вы выполняете NMU, вам для начала следует убедиться, что ваше намерение
сделать NMU ясно и понятно. Затем вам необходимо отправить заплату с
различиями между текущим пакетом и предполагаемой NMU в системе отслеживания
ошибок. Сценарий nmudiff из пакета devscripts
может вам в этом помочь.
Во время подготовки заплаты вам следует хорошо разобраться с практикой
создания данного пакета. Если вы будете это учитывать, что это уменьшит
бремя интеграции ваших изменений в обычный ход работы над пакетом и, таким
образом, увеличит шансы на то, что ваши изменения будут в дальнейшем
интегрированы. О практиках сборки данного пакета можно прочитать в файле
debian/README.source
.
Если у вас нет каких-либо веских причин не давать сопровождающему время для
самостоятельной работы, вам следует дать последнему это время (например,
загрузив пакет в очередь DELAYED
). Для задержек
рекомендуется использовать следующие значения:
Загрузка исправлений критичных для выпуска ошибок, о которых было сообщено более 7 дней назад, сопровождающий не проявлял активности в течении 7 дней, нет никакого указания на то, что исправление находится в стадии подготовки: 0 дней
Загрузка исправления только критичных для выпуска ошибок, о которых было сообщено более 7 дней назад: 2 дня
Исправление только критичных для выпуска ошибок и важных ошибок: 5 дней
Другие NMU: 10 дней
Эти задержки являются лишь примерами. В некоторых случаях, таких как
загрузка исправлений безопасности, либо исправлений тривиальных ошибок,
блокирующий перемещение пакета, желательно, чтобы исправленный пакет попал в
нестабильный выпуск
как можно скорее.
Иногда управляющие выпуском принимают решение разрешить NMU с более короткими задержками для некоторого подмножества ошибок (напр., для критичных для выпуска ошибок, о которых было сообщено более 7 дней назад). Кроме того, некоторые сопровождающие добавляют себя в список NMU с низким порогом и разрешают загружать NMU без какой-либо задержки. Но даже в этих случаях лучше всего дать сопровождающему несколько дней на самостоятельную работу и только потом осуществлять загрузку, особенно если заплата ранее не была доступна в системе отслеживания ошибок, либо если вы знаете, что сопровождающий в принципе активен.
После загрузки NMU вы становитесь ответственным за возможные проблемы, которые вы могли создать. Вам необходимо следить за пакетом (чтобы сделать это, подпишитесь на пакет в систем отслеживания пакетов).
Не разрешается бездумно выполнять NMU. Если вы выполняете NMU, и ясно, что сопровождающие активны и приняли бы заплату немного позже, либо если вы игнорируете рекомендации, приведённые в данном документе, ваша загрузка может привести к конфликту с сопровождающим. Вам всегда следует быть готовым к отстаиванию своего решения относительно любой загрузки NMU, которую вы выполняете.
Как и во время любой другой загрузки (исходного кода) при выполнении NMU
следует добавить запись в файл debian/changelog
,
сообщающую о том, что было изменено в данной загрузке. В первой строке
записи должно быть явно указано, что это загрузка NMU, напр.:
* Non-maintainer upload.
Присваивание версий при выполнении NMU разница для родных и неродных пакетов.
Если пакет является родным пакетом (без номера ревизии Debian в номере
версии), версия должны совпадать с версией загрузки её последним
сопровождающим, плюс +nmu
,
где X
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. Кроме того, это полезно для визуального выделения того, что пакет в архиве был подготовлен не тем, кто является его официальным сопровождающим.
Если вы загружаете пакет в тестируемый или стабильный выпуски, иногда вам
необходимо выполнить "разветвление" древа номера версии. Это делается,
например, в случае подготовки загрузок с исправлениями безопасности. Для
этого следует использовать версию вида
+deb
,
где X
uY
X
представляет собой мажорный номер версии, а
Y
является счётчиком, начинающимся с
1
. Например, поскольку jessie (Debian
8) является стабильным выпуском, загрузка NMU для исправления
проблем безопасности стабильного выпуска для пакета, имеющего версию
1.5-3
будет иметь версию
1.5-3+deb8u1
, а загрузка NMU с
исправлением безопасности для stretch будет иметь версию
1.5-3+deb9u1
.
Ожидание ответа на ваш запрос разрешения выполнить NMU не эффективно, так
как это предполагает, что тот, кто выполняет NMU, должен будет отвлечься от
проблемы, а затем снова вернутся к ней. Очередь DELAYED
(см. раздел 5.6.2, «Задержанные загрузки») позволяет разработчику, занимающемуся NMU, в то же
самое время выполнять все необходимые задачи. Например, вместо того, чтобы
сообщить сопровождающему о том, что вы собираетесь загрузить обновлённый
пакет в течении 7 дней, вам следует загрузить пакет в
DELAYED/7
и сообщить сопровождающему, что у него имеется
7 дней для того, чтобы отреагировать на это. В течении этого времени
сопровождающий может попросить вас ещё немного задержать загрузку, либо
отменить её.
Очередь DELAYED
не должна использоваться для
дополнительного давления на сопровождающего. В частности, важно, что у вас
имеется возможность отметить или задержать загрузку ещё немного до того
момента, как срок изначальной задержки закончиться, так как сопровождающий
не может сам отметить вашу загрузку.
Если вы выполняете NMU в DELAYED
, а сопровождающий
обновляет пакет до того, как закончится срок задержки, ваша загрузку будет
отклонена, поскольку в архиве уже будет доступна более новая версия. В
идеале сопровождающий позаботится о включении предлагаемых вами изменений
(или по меньшей мере о решении проблем, для решения который предназначаются
ваши изменения) в своей загрузке.
Когда кто-то выполняет NMU для вашего пакета, то это означает, что он хочет помочь вам поддерживать пакет в хорошей форме. Это позволяет пользователям быстрее получать исправленные пакеты. Вы можете попросить того, кто выполнил NMU, стать помощником сопровождающего для данного пакета. Когда кто-то выполнил NMU для вашего пакета, это вовсе не плохо; это лишь означает, что пакет интересен достаточному количеству людей, которые готовы работать над ним.
Для подтверждения NMU, добавьте предлагаемые изменения и запись журнала изменений в вашу собственную загрузку. Если вы не подтвердите NMU, добавив запись из журнала изменений NMU в ваш журнал изменений, сообщения об ошибках в системе отслеживания ошибок останутся закрытыми, но будут указаны как актуальные для версии пакета, которую загрузите вы.
Полностью NMU называется NMU исходного кода. Есть и другой тип NMU, а именно двоичные NMU или binNMU. BinNMU также представляет собой загрузку пакета тем, что не является его сопровождающим. Тем не менее, это загрузка исключительно двоичного кода.
При обновлении библиотеки (либо другой зависимости) пакеты, использующие её вероятно потребуется собрать заново. Поскольку изменения исходного кода не требуются, используется тот же самый пакет с исходным кодом.
BinNMU обычно выполняются на buildd по инструкции wanna-build. В файл
debian/changelog
добавляется запись, объясняющая то,
почему потребовалась загрузка, номер версии увеличивается в соответствии с
тем, как это описано в разделе 5.10.2.1, «Повторная компиляция или только двоичные NMU». Эту запись не следует
включать в следующую загрузку.
Buildd загружает пакеты для своей архитектуры в архив как двоичные
загрузки. Строго говоря, они являются binNMU. Тем не менее, обычно они не
называются NMU, они не добавляют запись в
debian/changelog
.
NMU представляют собой загрузки пакетов теми, кто не является сопровождающим этих пакетов. Существует также другой тип загрузок, когда загружаемый пакет не является вашим: это загрузки команды контроля качества. Загрузки, выполняемые командой контроля качества, являются загрузками осиротевших пакетов.
Загрузки, выполняемые командой контроля качества, очень похожи на загрузки
обычных сопровождающих: они могут исправлять всё, что угодно, даже
незначительные проблемы; присвоение номера версии происходит обычным путём,
также нет необходимости использовать задержку при загрузке. Отличие состоит
в том, что вы не указаны в полях Maintainer
и
Uploader
данного пакета. Кроме того, запись журнала
изменений при загрузке, выполняемой командой контроля качества, содержит
специальную первую строку:
* QA upload.
Если вы хотите выполнить NMU, и у вас складывается впечатление, что
сопровождающий не активен, вам следует проверить, является ли данный пакет
осиротевшим пакетом (эта информация отображается на странице пакета в
системе отслеживания пакетов). При выполнении первой загрузки командой
контроля качества в качестве сопровождающего устанавливается Debian
QA Group <packages@qa.debian.org>
. Для осиротевших пакетов,
загрузка которых командой контроля качества ещё не выполнялась, в качестве
сопровождающего имеют своего старого сопровождающего. Имеется список таких
пакетов: https://qa.debian.org/orphaned.html.
Вместо выполнения загрузки командой контроля качестве, вы можете усыновить пакет и стать его сопровождающим. Вам не нужно разрешение кого бы то ни было для того, чтобы усыновить осиротевший пакет, вы можете установить себя его сопровождающим и загрузить новую версию (см. раздел 5.9.5, «Усыновление пакета»).
Иногда вы занимаетесь исправлением и/или загрузкой пакета потому, что вы
являетесь членом команды по созданию пакетов (команда использует адрес
списка рассылки в качестве значения Maintainer
или
Uploader
, см. раздел 5.12, «Совместное сопровождение»), но вы не хотите добавлять
себя в поле Uploaders
, поскольку вы не планируете
постоянно участвовать в поддержке данного конкретного пакета. Если это
соответствует политике вашей команды, вы можете выполнить обычную загрузку,
не указывая себя в полях Maintainer
или
Uploader
. В этом случае вам следует начать вашу запись в
журнале изменения со следующей строки:
* Team upload.
Совместное сопровождение представляет собой термин, описывающий разделение
обязанностей по сопровождению пакета Debian между несколькими людьми. Эта
совместная работа почти всегда является отличной идеей, поскольку её
результатом обычно является более высокое качество пакета и более быстрое
исправление ошибок. Настоятельно рекомендуется, чтобы пакет с приоритетом
standard
, а также пакеты, являющиеся частью базового
набора пакетов, имели несколько сопровождающих.
Обычно имеется главный сопровождающий и один или больше помощников. Главный
сопровождающий является тем, чьё имя указано в поле
Maintainer
файла debian/control
.
Помощники сопровождающего — это все остальные сопровождающие, обычно они
указаны в поле Uploaders
файла
debian/control
.
В наиболее простом виде процесс добавления новых помощников сопровождающий крайне лёгок:
Предоставьте помощнику сопровождающего доступ к исходному коду, из которого
вы собираете ваш пакет. Обычно это предполагает, что вы используете систему
контроля версий, поддерживающую работу в сети, такую как
CVS
или Subversion
. Alioth (см. раздел 4.12, «Установка Debian FusionForge: Alioth»)
предоставляет помимо прочего и такие инструменты.
Добавьте имя и адрес электронной почты вашего помощника в поле
Uploaders
из первого раздела файла
debian/control
.
Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
Используя систему отслеживания пакетов (раздел 4.10, «Система отслеживания пакетов Debian»), помощники сопровождающего должны оформить подписку на соответствующий пакет с исходным кодом.
Другой формой совместного сопровождения является командное сопровождение,
которое рекомендуется в случае если вы сопровождаете несколько пакетов
вместе группой одних и тех же разработчиков. В этом случае на поля
Maintainer
и Uploaders
каждого пакеты
следует обратить особое внимание. Рекомендуется выбрать одну из двух
следующих схем:
Поместите в поле Maintainer
члена команды, который будет
ответственен за данный пакет. В поле Uploaders
поместите
адрес списка рассылки, а также тех членов команды, которые также будут
следить за пакетов.
Поместите адрес списка рассылки в поле Maintainer
. В
поле Uploaders
поместите членов команды, которые будут
следить за пакетом. В этом случае убедитесь, что список рассылки принимает
сообщения об ошибках без какого-либо дополнительного взаимодействия (типа
модерации для отправителей, не являющихся членами списка рассылки).
В любом случае не следует помещать всех членов команды в поле
Uploaders
. Это приводит к путанице — в обзорный список
пакетов разработчика (см. раздел 4.11, «Обзор пакетов разработчика») попадают пакеты, о который данный разработчик
фактически не заботится, и создаёт у пользователей ложное чувство того, что
пакет хорошо сопровождается. По той же самой причине члены команды не должны
добавлять себя в поле Uploaders
только потому, что они
загрузили данный пакет один раз, они могут выполнить “командную загрузку”
(см. раздел 5.11.7, «NMU и командные загрузки»). И наоборот, не следует оставлять пакет только с одним
адресом списка рассылки в поле Maintainer
, когда поле
Uploaders
пусто.
Пакеты обычно устанавливаются в тестируемый
выпуск после
того, как они прошли некоторую проверку
в
нестабильном
выпуске.
На всех архитектурах должна быть доступна одна и та же версия пакета, у
пакета не должно быть зависимостей, которые помешают установить этот пакет;
также они не должны иметь на момент установки в
тестируемый
выпуск известных критичных для выпуска
ошибок. Таким образом, тестируемый
выпуск всегда должен
быть близок кандидату на выпуск. Подробности см. ниже.
Сценарии, обновляющие тестируемый
выпуск, запускаются
дважды каждый день, сразу же после установки обновлённых пакетов; эти
сценарии имеют имя britney
. Они создают файлы
Packages
для тестируемого
выпуска,
но делают они это разумным способом; они пытаются избежать противоречивости
и использовать только те пакеты, которые не имеют ошибок.
Включение пакета из нестабильного
выпуска выполняется в
соответствии со следующими условиями:
Пакет должен быть доступен в нестабильном
выпуске в
течении 2, 5 или 10 дней в зависимости от его срочности (высокая, средняя
или низкая). Заметьте, что учитывается также и срочность прошлых загрузок,
точнее учитывается наивысшая срочность загрузки с момента последнего
перехода пакета в тестируемый
выпуск;
Пакет не должен иметь новых ошибок, критичных для выпуска (то есть,
критичных для выпуска ошибок в версии пакета, доступной в
нестабильном
выпуске, но отсутствующих в версии из
тестируемого
выпуска);
Пакет должен быть доступен на всех архитектурах, на которых он ранее был
собран в нестабильном
выпуске. dak
ls может помочь проверить эту информацию;
Пакет не должен ломать зависимости какого-либо уже доступного в
тестируемом
выпуске пакета;
Пакеты, от которых зависит данный пакет, должны либо быть доступны в
тестируемом
выпуске, либо должны быть приняты в
тестируемый
выпуск одновременно с этим пакетом (эти
пакеты будут приняты в случае, если они удовлетворяют всем необходимым
критериям);
Фаза проекта. Напр., автоматические переходы отключаются во время
заморозки тестируемого
выпуска.
Чтобы узнать, продвигается пакет к переходу в тестируемый
выпуск или нет, см. вывод сценария тестируемого
выпуска
на веб-странице тестируемого
выпуска, либо используйте программу grep-excuses,
которая является частью пакета devscripts
. Данная утилита легко может
использоваться в crontab(5) для того, чтобы у вас всегда
имелась информация о продвижении ваших пакетов в
тестируемый
выпуск.
Файл update_excuses
не всегда содержит точную причину
того, почему пакет был отклонён; вам может потребоваться выяснить это
самостоятельно, проверяя, что может сломаться из-за добавления вашего
пакета. Веб-страница тестируемого
выпуска содержит немного больше информации об обычных проблемах,
которые могут вызывать подобные затруднения.
Бывает так, что некоторые пакет никогда не включаются в
тестируемый
выпуск из-за того, что набор взаимных
зависимостей слишком сложен и не может быть разобран сценариями.
Подробности см. ниже.
Некоторый дополнительный анализ зависимостей доступен по адресу https://release.debian.org/migration/ — но предупреждаем, эта страница также содержит сборочные зависимости, которые не были рассмотрены britney.
Для сценария миграции в тестируемый
выпуск устаревание
означает следующее: в нестабильном
выпуске имеются разные
версии для выпускаемых архитектур (за исключением архитектур из
fuckedarches; fuckedarches представляет собой список архитектур, которые не
поддерживаются (в update_out.py
), но в настоящее время
он пуст). Устаревание не касается архитектур данного пакета, имеющихся в
тестируемом
выпуске.
Рассмотрим следующий пример:
alpha | arm | |
---|---|---|
testing | 1 | - |
unstable | 1 | 2 |
Пакет является устаревшим на архитектуре alpha
в
нестабильном
выпуске, и он не попадёт в
тестируемый
выпуск. Удаление пакета не поможет, пакет всё
равно считается устаревшим на архитектуре alpha
, и он не
будет перемещён в тестируемый
выпуск.
Тем не менее, если сопровождающий ftp удаляет пакет в
нестабильном
выпуске (здесь — на архитектуре
arm
):
alpha | arm | hurd-i386 | |
---|---|---|---|
testing | 1 | 1 | - |
unstable | 2 | - | 1 |
В этом случае пакет считается обновлённым на всех выпускаемых архитектурах в
нестабильном
выпуске (дополнительная архитектура
hurd-i386
не имеет значения, поскольку она не является
выпускаемой архитектурой).
Время от времени возникает вопрос о том, можно ли разрешить переход пакетов, которые ещё не были собраны на всех архитектурах. Нет. Просто нет и всё. (За исключением случая, если вы сопровождаете glibc или что-то подобное.)
Иногда какой-то пакет удаляется для того, чтобы был осуществлён переход
другого пакета. Это происходит только для того, чтобы позволить
другому пакету осуществить переход в случае, если он
уже готов. Допустим, напр., что пакет a
не может быть
установлен вместе с новой версией пакета b
; тогда пакет
a
может быть удалён для того, чтобы был осуществлён
переход пакета b
.
Конечно, имеется и другая причина для удаления пакета из
тестируемого
выпуска. Он имеет слишком много ошибок
(хотя даже одной критичной для выпуска ошибки достаточно).
Более того, если пакет был удалён из нестабильного
выпуска, и ни один пакет в тестируемом
выпуске не зависит
от него, то этот пакет будет автоматически удалён.
Ситуация, которая не может быть правильно обработана 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>
, если
такая ситуация возникла для одного из ваших пакетов.
Вообще же, статус пакета в тестируемом
выпуске ничего не
значит для перехода следующей версии этого пакета из
нестабильного
выпуска в тестируемый
, с
двумя исключениями. Во-первых, если у пакета уменьшается количество
критичных для выпуска ошибок, то он может осуществить переход даже в том
случае, если у него всё ещё остаются критичные для выпуска ошибки.
Во-вторых, если версия пакета в тестируемом
выпуске не
синхронизирована на разных архитектурах. Тогда любая архитектура может быть
обновлена до версии пакета с исходным кодом; тем не менее, это может
произойти только в том случае, если пакет ранее был перемещён вручную,
данная архитектура входит в список fuckedarches, либо для данной архитектуры
не было двоичного пакета в нестабильном
выпуске во время
перехода в тестируемый
выпуск.
Короче говоря, это означает следующее: единственный фактор, на который
влияет нахождение пакета в тестируемом
выпуске, состоит в
том, что новая версия этого пакета может быть проще добавлена.
Если вам интересны подробности, то britney работает следующим образом:
Просматриваются пакеты на предмет выявления того, являются они корректными кандидатами или нет. Это даёт нам список оснований для отказа в обновлении. Наиболее частыми основаниями того, почему пакет не рассматривается для обновления, являются то, что он слишком нов, имеет критичные для выпуска ошибки, устарел на каких-то архитектурах. Для этой части britney у управляющих выпуском имеются различные инструменты, называемые подсказками (см. ниже), которые используются для того, чтобы заставить britney рассмотреть данный пакет.
Далее начинается более сложная часть. Britney пытается обновить
тестируемый
выпуск путём установки корректных
кандидатов. Для этого britney пытается добавить каждого корректного
кандидата в тестируемый выпуск. Если число неустанавливаемых пакетов в
тестируемом
выпуске не увеличивается, то пакет
принимается. С этой точки зрения принятый пакет считается частью
тестируемого
выпуска, такой частью, что все последующий
проверки установок будут включать в себя этот пакет. Подсказки выпускающей
команды обрабатываются после или до этой основной работы в зависимости от
типа подсказок.
Если вы хотите ознакомиться с дополнительными подробностями, вы можете прочитать https://ftp-master.debian.org/testing/update_output/.
Подсказки доступны в https://ftp-master.debian.org/testing/hints/, также там вы можете
найти описание. При
помощи подсказок выпускающая команда Debian может блокировать или
разблокировать пакеты, замедлять или ускорять переход пакетов в
тестируемый
выпуск, удалять пакеты из
тестируемого
выпуска, принимать загрузки в testing-proposed-updates, либо изменять срочность
загрузки.
Тестируемый
выпуск получает пакеты из
нестабильного
выпуска в соответствии с описанными ранее
правилами. Тем не менее, в некоторых случаях необходимо загружать пакеты,
собранные только для тестируемого
выпуска. Для этого вы
можете использовать загрузку в testing-proposed-updates
.
Помните, что пакеты, загруженные туда, не обрабатываются автоматически, они
должны пройти через руки управляющего выпуском. Поэтому для того, чтобы
загружать свои пакеты туда, вам следует иметь для этого хорошее основание.
Для того, чтобы знать, что управляющие выпуском считаются хорошим
основанием, вам следует прочитать инструкции, которые они регулярно
публикуют в <debian-devel-announce@lists.debian.org>
.
Вам не следует загружать в testing-proposed-updates
, если
вы можете обновить ваши пакеты через нестабильный
выпуск. Если вы не можете этого сделать (например, из-за того, что у вас
имеется более новая версия в нестабильном
выпуске), вы
можете использовать эту возможность. Однако рекомендуется сначала попросить
на это разрешение у управляющего выпуском. Даже если пакет заморожен
обновления через нестабильный
выпуск всё равно возможны,
если загрузка через нестабильный
выпуск не тянет за собой
какие-либо новые зависимости.
Номера версий обычно выбираются путём добавления
+deb
X
uY
,
где X
представляет собой мажорный номер выпуска
Debian, а Y
является счётчиком, начинающимся с
1
. Напр.,
1:2.4.3-4+deb8u1
.
Убедитесь, что в вашей загрузке вы ничего не пропустили из следующего списка:
Убедитесь, что ваш пакет действительно должен пройти через
testing-proposed-updates
, и что он не может пройти через
нестабильный
выпуск;
Убедитесь, что вы включили в пакет лишь минимальное число изменений;
Убедитесь, что вы включили соответствующее объяснение в журнал изменений пакета;
Убедитесь, что вы указали кодовое-имя
тестируемого выпуска (напр., stretch
) в
качестве целевого выпуска;
Убедитесь, что вы собрали и протестировали ваш пакет в
тестируемом
, а не в нестабильном
выпуске;
Убедитесь, что номер версии пакета выше номера версии, входящей в
тестируемый
выпуск и в
testing-proposed-updates
, а также ниже, чем в
нестабильном
выпуске;
После загрузки и успешной сборки на всех платформах, свяжитесь с выпускающей
командой по адресу <debian-release@lists.debian.org>
и попросите их одобрить вашу
загрузку.
Все ошибки, имеющие высокую важность, по умолчанию считаются критичными для
выпуска; в настоящее время это ошибки с важностью
critical
, grave
и
serious
.
Предполагается, что такие ошибки влияют на шансы того, будет пакет выпущен в
составе стабильного
выпуска Debian или нет. В общем
случае, если пакет имеет открытые сообщения о критичных для выпуска ошибках,
он не попадёт в тестируемый
выпуск и, соответственно, не
будет выпущен в составе стабильного
выпуска.
Число ошибок в пакетах нестабильного
выпуска представляет
собой все критичные для выпуска ошибки, которые помечены как применимые к
комбинациям
пакет
/версия
,
доступным в нестабильном выпуске для выпускаемой архитектуры. Число ошибок в
пакетах тестируемого
выпуска определяется аналогичным
образом.
Структура архивов выпусков такова, что они могут содержать только одну
версию пакета; пакет определяется его именем. Поэтому, когда пакет с
исходным кодом acmefoo
устанавливается в
тестируемый
выпуск вместе с соответствующими двоичными
пакетами acme-foo-bin
, acme-bar-bin
,
libacme-foo1
и libacme-foo-dev
, старая
версии пакетов удаляются.
Тем не менее, старая версия может предоставлять двоичный пакет со старой
библиотекой с тем же именем, такой как libacme-foo0
.
Удаление старого пакета acmefoo
приведёт к удалению
libacme-foo0
, что в свою очередь приведёт к удалению всех
зависящих от неё пакетов.
Очевидно, эта ситуация касается пакетов, которые в своих разных версиях предоставляют разные наборы двоичных пакетов (в основном библиотеки). Тем не менее, она также касается пакетов, которые имеют зависимости от конкретных версий, задаваемые через ==, <= или <<.
Если набор двоичных пакетов, предоставляемый пакетом с исходным кодом,
меняется подобным образом, все пакеты, которые зависят от старых двоичных
пакетов должны быть обновлены таким образом, что они должны зависеть от
новых двоичных пакетов. Поскольку установка такого пакета с исходным кодом
в тестируемый
выпуск ломает все пакеты, которые зависят
от него в тестируемом
выпуске, следует быть немного более
внимательным: все зависящие пакеты сами должны быть обновлены и готовы к
установке, так чтобы они не сломалось, и когда всё будет готово, обычно
требуется ручное вмешательство управляющего выпуском или его ассистента.
Если у вас имеются подобные проблемы со сложной группой пакетов, свяжитесь с
<debian-devel@lists.debian.org>
or <debian-release@lists.debian.org>
for help.
[3] См. Руководство по политике Debian для получения советов о том, к какому разделу относится тот или иной пакет.
[4] В прошло подобные NMU использовали номер третьего уровня в части Debian редакции для обозначения статуса повторной компиляции; тем не менее, этот синтаксис был двусмыслен в случае родных пакетов и не позволяя правильно определять порядок заново скомпилированных NMU, NMU исходного кода и NMU безопасности одного и того же пакета, потому он был отброшен и заменён новым синтаксисом.