При возникновении желания отправить исправление мейнтейнеру пакета Debian
возникает вопрос, как правильно изменить код пакета и как отправить патч.
1. Получаем последнюю версию пакета с исходным кодом и устанавливаем
необходимые для его сборки зависимости.
Одним из методов является использование утилиты 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, установка
которого повлечет за собой установку наборов инструментов, полезных для
разработчиков пакетов.
2. Внесение изменений.
Для фиксации факта начала работы над внесением изменения в пакет пользователем,
не являющимся мейнтейнером, выполним команду (NMU = Non Maintainer Upload):
$ dch --nmu
Этот шаг также позволит гарантировать, что после сборки пакета мы не перетрем
загруженный ранее оригинальный пакет с исходными текстами.
2.1. Изменяем служебные файлы пакета.
Заходим в поддиректорию debian и правим при необходимости нужные файлы.
Внесенные изменения отражаем путем выполнения команды dch (если изменений
несколько утилиту нужно запустить несколько раз).
2.2. Изменяем файлы оригинальной программы, поставляемой в пакете.
При изменении файлов 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
2.2.1. Импортируем существующий патч.
Если изменения уже оформлены в 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, но пока не будет по умолчанию
применен к коду.
2.2.1. Создаем новый патч.
Если изменения еще не оформлены в виде патча, нужно указать 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
3. Тестируем внесенные изменения
Собираем измененный пакет:
$ debuild -us -uc
проверяем его работоспособность, установив в систему через dpkg или debi.
4. Генерируем патч для отправки мейнтейнеру.
После выполнения всех ранее указанных шагов в директории должно находиться два
.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 на изменений в публичном репозитории.
|
