NMU
Материал из ALT Linux Wiki
Обновление пакета не сопровождающим (Non-Maintainer Upload, далее — NMU) — экстренное обновление пакета в репозитории кем-либо, кроме сопровождающих пакет. Предпринимается в случае наличия серьёзных проблем в пакете и недоступности сопровождающего или отсутствия у него возможности эти проблемы исправить.
Помните, что NMU — это акт помощи; майнтейнер может быть благодарен за неё. При этом ответственность за судьбу пакета несёт майнтайнер и поэтому он вправе в дальнейших сборках пакета делать то, что сочтёт нужным.
Содержание |
Условия, требующие подготовки NMU
NMU выполняется в случае выполнения одного из нижеследующих условий:
- наличие серьёзных ошибок в пакете (major и выше), висящих на нем в системе отслеживания ошибок http://bugzilla.altlinux.org,
- отсутствие реакции мантейнера на запросы от любого из участников ALT Linux Team, выполненные через список рассылки devel@, в течении двух недель,
- наличие проблем с безопасностью в пакете,
- несобираемость пакета в изменённой сборочной среде (например при обновлении gcc, glibc и т. д.).
Общие соображения
Перед тем, как делать NMU, следует постараться найти контакт с текущим майнтейнером — обязательно при помощи отчёта об ошибке в bugzilla, а также электронной почты, IM, телефона или прямого обращения по мере возможности и уместности.
Если в течение срока от суток до месяца, в зависимости от срочности проблемы (серьёзная с безопасностью или разваливающая существенную часть репозитория, мешающая не единицам пакетов и/или пользователей), положительный ответ не поступил или проблема не исправлена — следует написать в devel@ запрос и готовить обновление, если оно ещё не собрано для своих нужд.
Если возможно, подготовьте, проверьте и предложите в bugzilla патч, исправляющий проблему — это облегчит работу майнтейнеру. В любом случае настоятельно рекомендуется прислать майнтейнеру изменения в спеке и патчах, поскольку забыв про NMU — он может забыть и применить изменения к своей сборке, из которой будет исходить при составлении следующего пакета. В результате исправления могут быть откаченными, а то и вовсе потерянными.
Подготовка
При исправлении следует учесть, что изменения должны быть минимальными и настолько неинтрузивными, насколько это возможно. Не следует «зачищать» спек, передвигать модули или файлы и вообще чинить то, что не сломано — этим следует заниматься майнтейнеру или команде сопровождающих.
Не забывайте и Гиппократа: «превыше всего, не навреди». Лучше на пакете будет висеть открытый багрепорт по серьёзной проблеме, чем она будет «разрешена» нерабочим патчем или даже исправлена, но сломано ещё что-нибудь.
Указание Packager
При отсутствии поля Packager в пакете его необходимо добавить, указав в нём реального майнтейнера, чтобы пакет не перешёл к вам (со всеми своими багами).
Версионирование
Зачастую исправление можно сделать в рамках той же базовой версии пакета; при этом стоит добавить дополнительное число, отделённое точкой и начинающееся с «1» к содержимому тега Release, чтобы не пересечься с нормальной нумерацией версий у основного майнтейнера.
Например, пакет, собранный майнтейнером с релизом alt3, автоматически пересобранный QA Team Robot с релизом alt3.1 — при NMU должен получить релиз alt3.1.1.
Соответствующая строка в changelog пакета должна содержать слово «NMU», а также ссылки на номера багрепортов. Майнтейнеру следует сохранить или импортировать эту запись при дальнейшем сопровождении пакета.
Управление доступом
Майнтейнер в данное время может предоставлять или изымать возможность публикации ведомого им пакета другими участниками команды, передавать им пакет или объявлять его бесхозным при помощи управления ACL пакетов через git.alt.
