Чеклист перед релизом
Что проверить перед публикацией пакета.
На этой странице
Этот чеклист — финальная проверка перед отправкой пакета в репозиторий. Пройдите все пункты последовательно.
1. Исходники и источники
-
Source0URL доступен и скачивается - Архив соответствует указанной версии
- Источник понятен и воспроизводим: релизный архив, tag или зафиксированный commit
- Если используете
.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— понятное описание на английском -
%distне зашит вручную вReleaseи не подменяется без необходимости
Как проверить лицензию
# Распаковать исходники
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
- Bundled-зависимости не тащатся без явной причины и объяснения
Как проверить полноту BuildRequires
# Лучший способ — сборка в mock
mock -r <профиль_из_/etc/mock> --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}) - Нет ручных отключений
AutoReq/AutoProv, если без них можно обойтись
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-сборка или сборка в ABF проходит в чистой среде
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 ==="
Проверьте понимание
- Почему нужно сбрасывать Release при обновлении Version?
- Как убедиться, что все BuildRequires указаны?
- Зачем нужен
%config(noreplace)? - Что проверить в лицензии перед публикацией?
- Какой минимальный smoke-тест нужен для CLI-утилиты?
Далее: Сопровождение пакета