Этот чеклист — финальная проверка перед отправкой пакета в репозиторий. Пройдите все пункты последовательно.

1. Исходники и источники

• Source0 URL доступен и скачивается
• Архив соответствует указанной версии
• Если используете .abf.yml — URL и хеши актуальны
• Все Source-файлы добавлены в git-репозиторий (или доступны по URL)
• Патчи применяются чисто (без fuzz, без reject)
• Патчи, вошедшие в новую версию upstream, удалены из SPEC

2. SPEC-файл: метаданные

• Name — совпадает с именем upstream-проекта (в нижнем регистре)
• Version — совпадает с версией upstream
• Release — сброшен в 1%{?dist} при обновлении Version
• Summary — краткое, информативное, на английском
• License — корректный SPDX-идентификатор, соответствует реальной лицензии
• URL — ссылка на домашнюю страницу проекта (актуальна)
• %description — понятное описание на английском

Как проверить лицензию

# Распаковать исходники
tar xf mypackage-1.0.tar.gz

# Найти файлы лицензий
find mypackage-1.0 -iname 'LICENSE*' -o -iname 'COPYING*' | head

# Прочитать и определить тип
cat mypackage-1.0/LICENSE

Сверьте с SPDX License List. Укажите точный идентификатор: MIT, GPL-3.0-or-later, Apache-2.0, BSD-3-Clause.

3. SPEC-файл: зависимости

• Все BuildRequires указаны явно (не полагайтесь на то, что стоит на вашей системе)
• Для библиотек предпочитайте pkgconfig(name) вместо name-devel
• Нет лишних явных Requires (RPM определяет зависимости от .so автоматически)
• Если пакет требует конкретную программу (curl, git) — укажите Requires

Как проверить полноту BuildRequires

# Лучший способ — сборка в mock
mock -r rosa-13.1-x86_64 --rebuild mypackage.src.rpm

# Если mock недоступен — сравнить с минимальной установкой

4. SPEC-файл: секции сборки

• %prep — используется %autosetup (или %setup + %patch)
• %build — используются стандартные макросы (%configure, %cmake, %meson, etc.)
• %install — используются макросы (%make_install, %cmake_install, etc.)
• %check — тесты запускаются (или объяснено, почему отключены)
• Нет жёстко заданных путей (/usr/lib64) — только макросы (%{_libdir})

5. SPEC-файл: секция %files

• Используются макросы путей (%{_bindir}, %{_libdir}, etc.)
• %license для файлов лицензии
• %doc для документации
• %config(noreplace) для конфигурационных файлов
• Для библиотек: .so.* в основном пакете, .so (без версии) в -devel
• .la файлы удалены
• Нет «Installed (but unpackaged)» файлов

6. SPEC-файл: changelog

• Формат записи: * День Месяц Число Год Имя <email> - Версия-Релиз
• Описано, что изменилось
• Записи в хронологическом порядке (новые сверху)

%changelog
* Mon Feb 03 2025 Your Name <your@email.com> - 2.1.0-1
- Update to 2.1.0
- Remove upstreamed patch for GCC 14

7. Качество сборки

• rpmbuild -ba завершается без ошибок
• rpmlint — нет ошибок (E:), предупреждения (W:) объяснимы
• Пакет устанавливается: sudo dnf install ./mypackage-*.rpm
• Приложение запускается и работает (smoke-тест)
• Пакет удаляется чисто: sudo dnf remove mypackage
• mock-сборка проходит (если mock доступен)

8. Подпакеты (если есть)

• -devel зависит от основного пакета с %{?_isa}
• Заголовки, .so-линк, .pc-файлы — только в -devel
• ldconfig вызывается для пакетов с .so.*
• -doc помечен BuildArch: noarch

9. Публикация

• Все файлы добавлены в git и запушены
• Платформа ABF выбрана правильно
• Сборка на ABF проходит успешно
• Пакет доступен в личном репозитории и устанавливается

Быстрая команда для финальной проверки

# Полная пересборка + проверка
rpmbuild -ba mypackage.spec && \
    rpmlint ~/rpmbuild/RPMS/*/*.rpm ~/rpmbuild/SRPMS/*.rpm && \
    echo "=== ALL CHECKS PASSED ==="

Проверьте понимание

1. Почему нужно сбрасывать Release при обновлении Version?
2. Как убедиться, что все BuildRequires указаны?
3. Зачем нужен %config(noreplace)?
4. Что проверить в лицензии перед публикацией?
5. Какой минимальный smoke-тест нужен для CLI-утилиты?

Далее: Сопровождение пакета