TypicalPackagingErrors/PatchesVsFiles: различия между версиями
(Import from freesource.info) |
Ilis (обсуждение | вклад) (→Ссылки) |
||
Строка 85: | Строка 85: | ||
=== Ссылки === | === Ссылки === | ||
* [http://lists.altlinux.org/pipermail/community/2007-February/189295.html http://lists.altlinux.org/pipermail/community/2007-February/189295.html] | * [http://lists.altlinux.org/pipermail/community/2007-February/189295.html http://lists.altlinux.org/pipermail/community/2007-February/189295.html] | ||
[[Категория:TypicalPackagingErrors|{{SUBPAGENAME}}]] |
Версия от 18:48, 13 марта 2009
Типичные ошибки: почему патчи лучше переписывания файлов
Иногда в пакете возникает необходимость заменить один или несколько файлов на более новые или лучшие версии. Иногда это делают, добавляя в пакет нужный файл целиком и копируя на место оригинала. Лучше так не делать, а изготовить патч, по следующим причинам:
- Патчи обычно меньше по размеру, чем целые файлы, потому что содержат только измененные строки и небольшой контекст.
- Важные изменения оригинального файла в upstream труднее пропустить, используя патч, т.к. патчи формата diff проверяются на соответствие контекста.
Как делать патчи
Для получения патчей над деревом исходников удобно воспользоваться утилитой gendiff из пакета rpm-build. Сделайте копии оригинальных файлов с выделяющимся суффиксом, например, .orig-gcc34 для патча на сборку с GCC 3.4. Произведя изменения, смените каталог на уровень выше дерева, к которому будет применяться патч, и воспользуйтесь утилитой, указав использованный суффикс:
gendiff mysoftware-0.1.2 .orig-gcc34
> Что лучше почитать перед тем как заниматься изготовлением > > собственных патчей?
Краткая инструкция для "начинающих".
Распаковать апстримные сырцы. Допустим что они распакованы в папку name-1.0/
Далее надо зайти в эту директорию. Перед изменением каждого файла надо создать его копию с с расширением .orig
То есть например если собираешься менять Makefile.am - надо скопировать его как Makefile.am.orig Я обычно делаю это командой cp src/Makefile.am{,.orig} После чего надо внести во все файлы необходимые изменения. Можно даже собирать из этой директории, вносить дополнительные изменения по результатам пересборки, и т.д.
Когда изменения будут готовы - наступает самое тяжелое. Надо придумать имя для патча.
ALT Packaging policy (http://docs.altlinux.ru/alt/devel/ch01.html#id2865952) рекомендует давать патчам имена, состоящие из имени пакета, версии, "происхождения" и причины патча.
Например, имя патча для нашего гипотетического пакета может быть name-1.0-alt-link-fixes.patch
Тогда надо выйти в "родительскую" директорию (где находится каталог с исходниками name-1.0/) и сказать gendiff name-1.0 .orig На экран будет выведен патч, сгенерированный как разница между сохраненными ранее файлами .orig и измененными файлами без .orig.
Если нравится что получилось - надо сохранить этот патч как отдельный файл.
gendiff name-1.0 .orig > /RPM/SOURCES/name-1.0-alt-link-fixes.patch
Затем в спеке надо будет подключить этот патч в двух местах.
Первое из них - это запись о патче. Рекомендую положить ее рядом с тегом Source. Перед патчем желательно поместить какой-нибудь комментарий типа для чего этот патч.
- Name's upsteam don't want my patch, so I place it here. This make
all plugins properly linked. Patch0: name-1.0-alt-link-fixes.patch
Вторая часть - это собственно, применение патча.
это надо делать в секции %prep после макроса %setup Желательно скопировать комментарий для патча из верхней части, чтобы было понятно что патч делает и было легко его отключать.
Для патча, созданного через gendiff - надо написать следующее:
- Name's upsteam don't want my patch, so I place it here. This make
all plugins properly linked. %patch0 -p1 Где номер 0 соответствует патчу номер 0.
Вот собственно и все. Если надо отключить патч, просто замените символ процента в %patch0 на символ решетки(#). Тогда он станет комментарием.
Надеюсь, это маленькое хауту поможет в благородном деле уменьшения количества обработанных напильником программ в вашем многострадальном /usr/local.