При возникновении желания отправить исправление мейнтейнеру пакета 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 на изменений в публичном репозитории.
URL: http://raphaelhertzog.com/2011/07/04/how-to-prepare-patches-.../
Обсуждается: http://www.opennet.me/tips/info/2593.shtml
Спасибо, полезно!
Увидел статью на DPlanet. Хороший док, ему бы в офдокументацию попасть.
http://wiki.debian.org/ru/patchpackages
Спасибо.
Спасибо, очень интересно!