Ошибки новичков

1. Неправильный уровень -p

Симптом:

can't find file to patch at input line 7
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--- a/configure.ac
+++ b/configure.ac

Причина: используется -p0, но патч создан через git format-patch (пути начинаются с a/ и b/).

Решение: используйте -p1:

%autosetup -p1

2. Патч создан относительно неправильного каталога

Симптом:

can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--- htop-3.3.0/src/htop.c
+++ htop-3.3.0-patched/src/htop.c

Причина: diff выполнен с путями htop-3.3.0/..., и при -p1 отрезается htop-3.3.0/, что правильно. Но если патч создан с другой структурой, пути не совпадут.

Решение: проверьте пути внутри патча. Первый компонент (до первого /) отрезается при -p1. Убедитесь, что после отрезания путь совпадает со структурой каталога в ~/rpmbuild/BUILD/htop-3.3.0/.

3. Забыли добавить патч в SPEC

Симптом: файл патча лежит в SOURCES/, но не применяется.

Причина: нет тега Patch0: в SPEC.

Решение: добавьте тег Patch:

Source0:  ...tar.gz
Patch0:   0001-my-fix.patch

4. Правка сгенерированных файлов вместо исходных

Что сделали: создали патч для configure (8000 строк) вместо configure.ac (5 строк).

Почему плохо:

• Огромный патч, который сломается при любом изменении
• configure — сгенерированный файл, его нужно пересоздавать через autoreconf
• Невозможно понять, что именно изменилось

Правильный подход:

1. Правьте configure.ac или Makefile.am
2. Включите в SPEC autoreconf -fi после %autosetup
3. Добавьте BuildRequires: autoconf automake libtool

5. Бинарные файлы в патче

Симптом: патч содержит строки вроде:

Binary files a/icon.png and b/icon.png differ

Или гигантский base64-блок.

Причина: вы добавили или изменили бинарный файл (картинку, шрифт и т.д.)

Решение: бинарные файлы не должны быть в патчах. Добавьте их как отдельные Source:

Source1:  htop-custom-icon.png

%prep
%autosetup -p1
cp %{SOURCE1} icons/htop.png

6. Патч с неправильными переносами строк

Симптом: патч выглядит нормально, но при применении ошибки:

Hunk #1 FAILED at 42.

Причина: файл в архиве имеет Unix-переносы (\n), а патч создан с Windows-переносами (\r\n) или наоборот.

Решение: конвертируйте переносы строк:

dos2unix my.patch
# или
sed -i 's/\r$//' my.patch

7. Не обновили %changelog при добавлении патча

Симптом: rpmlint предупреждает или ревьюер отклоняет пакет.

Правило: каждое изменение в SPEC должно отражаться в %changelog. Используйте rpmdev-bumpspec:

rpmdev-bumpspec -c "Add patch to disable -Werror" htop.spec

Это автоматически:

• Увеличит Release
• Добавит запись в %changelog с текущей датой

8. Патч применяется, но autoreconf ломает сборку

Симптом: после autoreconf -fi появляются ошибки вроде:

configure.ac:25: error: possibly undefined macro: AC_PROG_LIBTOOL

Причина: не установлен пакет libtool или другая Autotools-зависимость.

Решение: убедитесь, что все BuildRequires установлены:

BuildRequires: autoconf automake libtool

Когда НЕ нужен патч

Не всякое изменение требует патча. Иногда есть более простые способы:

Использование sed в %prep

Если нужно заменить строку в одном файле:

%prep
%autosetup
# Убираем -Werror — проще, чем поддерживать патч
sed -i 's/-Werror//g' configure.ac
autoreconf -fi

Когда это допустимо:

• Изменение тривиально (замена одной строки)
• Замена не зависит от контекста (не сломается при обновлении)
• Вы документируете, что и зачем меняете (комментарий в SPEC)

Когда лучше патч:

• Изменение многострочное
• Нужен контекст (патч проверяет, что окружающий код не изменился)
• Изменение нужно отслеживать и ревьюить

Использование configure-опций

Вместо патча для отключения фичи — используйте опции configure:

%configure --disable-werror --enable-unicode

Проверьте доступные опции:

./configure --help | grep -i werror

Использование переменных окружения

Некоторые параметры можно передать через переменные:

%build
CFLAGS="%{optflags} -Wno-error" %configure
%make_build

Использование CFLAGS/CXXFLAGS

Если проект добавляет -Werror, его можно «перебить» через флаги:

%build
%configure
%make_build CFLAGS="%{optflags}"

Несколько патчей и их порядок

Когда у пакета несколько патчей, порядок важен:

# Сначала структурные изменения
Patch0:  0001-Disable-Werror.patch
# Потом бэкпорты
Patch1:  0002-Backport-memory-fix.patch
# Потом дистрибутив-специфичные
Patch2:  0003-ROSA-default-config.patch

%autosetup -p1 применит их в порядке: Patch0, Patch1, Patch2.

Если Patch1 зависит от изменений в Patch0 (например, правит тот же файл в том же месте) — порядок критичен. Если переставить — получите конфликт.

Условные патчи

Иногда патч нужен только для определённой архитектуры или версии:

# Патч только для aarch64
%ifarch aarch64
Patch10: htop-aarch64-fix.patch
%endif

Или с использованием %autosetup и условного %patch:

%prep
%autosetup -N            # -N = не применять патчи автоматически
%autopatch -p1 0 1 2     # применить Patch0, Patch1, Patch2
%ifarch aarch64
%autopatch -p1 10        # применить Patch10 только на aarch64
%endif

Полезные команды для работы с патчами

# Посмотреть, какие файлы затрагивает патч:
grep '^diff --git' my.patch
# или:
lsdiff my.patch          # из пакета patchutils

# Посмотреть статистику:
diffstat my.patch         # из пакета diffstat

# Проверить, применится ли патч (без реального применения):
cd ~/rpmbuild/BUILD/htop-3.3.0/
patch -p1 --dry-run < ~/rpmbuild/SOURCES/my.patch

# Откатить патч:
patch -p1 -R < ~/rpmbuild/SOURCES/my.patch

Итоги

В этом практикуме вы научились:

1. Понимать, когда и зачем нужны патчи
2. Создавать патчи через git format-patch (рекомендуемый способ)
3. Применять патчи в SPEC через %autosetup -p1
4. Делать backport коммитов из upstream через git cherry-pick
5. Разрешать конфликты при наложении патчей
6. Правильно именовать и нумеровать патчи
7. Обслуживать патчи при обновлении версии пакета
8. Выбирать между патчем, sed, configure-опциями и переменными окружения