При возникновении желания отправить исправление мейнтейнеру пакета Debian возникает вопрос, как правильно изменить код пакета и как отправить патч.
Contents
Получаем исходный код и устанавливаем зависимости для его сборки
Одним из методов является использование утилиты dget, входящей в состав пакета devscripts, которая позволяет напрямую загрузить пакет с исходным кодом по URL, который можно найти в dsc-файле, который можно загрузить из сисетмы трекинга пакетов.
Если попытаться использовать apt-get, временами может быть выведено предупреждение, что пакет обслуживается в системе управления версиями:
$ apt-get source wordpress [...] NOTICE: 'wordpress' packaging is maintained in the 'Git' version control system at: git://git.debian.org/git/collab-maint/wordpress.git [...]
В этом случае следует использовать утилиту debcheckout для загрузки кода напрямую из репозитория системы управления версиями:
$ debcheckout wordpress declared git repository at git://git.debian.org/git/collab-maint/wordpress.git git clone git://git.debian.org/git/collab-maint/wordpress.git wordpress ... Cloning into wordpress...
Дополнительно рекомендуется установить мета-пакет packaging-dev, установка которого повлечет за собой установку наборов инструментов, полезных для разработчиков пакетов.
Внесение изменений
Для фиксации факта начала работы над внесением изменения в пакет пользователем, не являющимся мейнтейнером, выполним команду (NMU = Non Maintainer Upload):
$ dch --nmu
Этот шаг также позволит гарантировать, что после сборки пакета мы не перетрем загруженный ранее оригинальный пакет с исходными текстами.
Изменяем служебные файлы пакета
Заходим в поддиректорию debian и правим при необходимости нужные файлы. Внесенные изменения отражаем путем выполнения команды dch (если изменений несколько утилиту нужно запустить несколько раз).
Изменяем файлы оригинальной программы, поставляемой в пакете
При изменении файлов upstream-проекта имеет значение какой из форматов задействован в используемом пакете с исходными текстами ("1.0, "3.0 (quilt)" или "3.0 (native)", разница сводится к формированию одного большого патча или размещении каждого патча в отдельном файле), а также тип системы патчей (можно посмотреть запустив what-patch). В данной заметке рассматривается ситуация использования рекомендованного формата "3.0 (quilt)" (рекомендации будут работать и для формата "1.0", но для этого нужно настроить ~/.quiltrc в соответствии с инструкцией /usr/share/doc/quilt/README.source)
Применяем в коду оригинального проекта все патчи, выполнив:
$ quilt push -a
Если патчей в пакете ещё нет, создаем вручную поддиректорию debian/patches:
$ mkdir debian/patches
Импортируем существующий патч
Если изменения уже оформлены в upstream-проекте в виде патча, то импортировать данный патч можно следующим образом:
$ quilt import -P fix-foobar.patch /tmp/patch Importing patch /tmp/patch (stored as fix-foobar.patch) $ quilt push Applying patch fix-foobar.patch [...] Now at patch fix-foobar.patch
Опция "-P" позволяет выбрать на свое усмотрение имя для сохранения патча в директории debian/patches/. После выполнения указанных действий патч будет добавлен в директорию debian/patches/series, но пока не будет по умолчанию применен к коду.
Создаем новый патч
Если изменения еще не оформлены в виде патча, нужно указать quilt о необходимости создать новый патч:
$ quilt new fix-foobar.patch Patch fix-foobar.patch is now on top
Далее указываем все файлы, которые будут изменены в результате нашей деятельности. Для каждого изменяемого файла запускаем "quilt add", после чего quilt создаст для каждого из этих файлов резервную копию, на основе оценки изменений с которой в последствии будет сгенерирован патч. Теперь правим любым удобным способом нужные файлы. Если файлы планируется отредактировать вручную, вместо "quilt add" можно запустить "quilt edit".
$ quilt edit foobar.c File foobar.c added to patch fix-foobar.patch
После того как все изменения внесены, генерируем патч:
$ quilt refresh Refreshed patch fix-foobar.patch
Тестируем внесенные изменения
Собираем измененный пакет:
$ debuild -us -uc
проверяем его работоспособность, установив в систему через dpkg или debi.
Генерируем патч для отправки мейнтейнеру
После выполнения всех ранее указанных шагов в директории должно находиться два .dsc-файла, изначальный и новый, например:
$ cd .. $ ls wordpress_*.dsc ../wordpress_3.0.5+dfsg-1.1.dsc ../wordpress_3.0.5+dfsg-1.dsc
Сгенерировать патч для отправки мейнтейнеру можно командой debdiff:
$ debdiff wordpress_3.0.5+dfsg-1.dsc wordpress_3.0.5+dfsg-1.1.dsc >/tmp/wp-debdiff
Для отправки патча /tmp/wp-debdiff мейнтейнеру можно использовать утилиту bugreport, указав в роли тега "patch". Для автоматизации отправки можно использовать утилиту nmudiff.
Если работа осуществлялась с копией из системы управления исходными текстами (выполняли debcheckout), то вместо debdiff можно сгенерировать diff-файл встроенными средствами используемой системы контроля версий (git diff, svn diff и т.п). В случае использования распределенной системы контроля версий (git, bzr, mercurial) возможно следует оформить все модификации в виде отдельного набора изменений. Вместо отправки одного патча, возможно потребуется отправить серию патчей или отправить URL на изменений в публичном репозитории.