При возникновении желания отправить исправление мейнтейнеру пакета 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.dev/tips/info/2593.shtml