Выбрать ветку (тег)
Найти файл
Клонировать
README.md

Spec Checker — МосТех.ОС

Настольный редактор RPM spec-файлов с проверкой правил репозитория. Стандарт из предоставленного DOCX перенесен в STANDARD.md. Отличия профиля МосТех.ОС описаны в разделе 25: отключение debug-пакетов считается ошибкой даже при наличии объясняющего комментария. Профиль учитывает принятые примеры mos-gtk.spec и mostech-feedback.spec: пакетные блоки с %files до %prep, Group и выравнивание тегов табуляцией допустимы.

Запуск

Нужны Python 3.10+ и Tkinter/Tk с поддержкой графического дисплея. Для PDF-отчетов нужна библиотека ReportLab 4.0+ и шрифт с кириллицей (например, системный DejaVu Sans). Для системных диалогов KDE/Dolphin используется kdialog; при его отсутствии доступен диалог Tkinter. В окружении МосТех.ОС, где разрабатывался проект, эти компоненты доступны.

cd /home/user/projects/spec-checker
python3 run.py
# Или сразу открыть spec:
python3 run.py examples/foo.spec

Также можно запускать ./start.sh. При установке проекта через python3 -m pip install . доступна команда spec-checker. Если Python сообщает об отсутствии tkinter, установите системный пакет Tkinter для используемой версии Python через менеджер пакетов МосТех.ОС. При запуске из исходников ReportLab можно установить системным менеджером пакетов или через python3 -m pip install 'reportlab>=4.0'; при pip install . он устанавливается как зависимость приложения.

Работа с приложением

  1. Редактор: открыть файл через диалог, редактировать, отменять/повторять изменения, искать текст, сохранять или выбирать другой путь. Проверка текущего текста запускается автоматически после правок и по F5.
  2. Структура: для каждой секции видны строки, правильность порядка, наличие в стандарте и число замечаний. Отсутствующие обязательные секции показаны отдельно. Двойной щелчок переводит редактор на нужную строку.
  3. Замечания: ошибки, предупреждения и пункты, требующие проверки; каждое замечание содержит строку, правило и объяснение.
  4. Воздействие на ОС: статические риски из spec и расширенная проверка RPM.
  5. Стандарт и охват: текст стандарта и границы автоматической проверки.

Ctrl+O — открыть, Ctrl+S — сохранить, Ctrl+Shift+S — сохранить как, Ctrl+Z — отменить, Ctrl+Y — повторить, F5 — проверить. PDF-отчет и JSON экспортируются отдельными кнопками. Диалоги открытия spec, выбора RPM, каталогов и сохранения используют системное окно KDE с привычными местами, фильтрами и оформлением окружения Dolphin.

Поддерживаются UTF-8, UTF-8 с BOM и Windows-1251. Исходная кодировка и стиль LF/CRLF сохраняются. Сохранение атомарное, с сохранением прав файла. Если файл изменился на диске, приложение запрашивает подтверждение перезаписи. При закрытии или открытии другого файла предлагается сохранить правки.

Отчет PDF

Кнопка «Отчет PDF…» сохраняет читаемый отчет о текущем тексте редактора. Он содержит итог проверки, первоочередные исправления, таблицу состояния секций, подробные замечания со строками, пунктами стандарта, фрагментами spec и рекомендациями, результаты анализа воздействия на ОС и дальнейшие шаги.

Отчет отмечает несохраненные правки, незавершенные проверки, отсутствие RPM-разбора или расширенного анализа ОС. Выбранные RPM, корень целевой ОС и buildroot указываются вместе с завершенными RPM-результатами. Кириллица встраивается в PDF как шрифт; текст можно искать и копировать. Длинные списки переносятся на новые страницы с повторением заголовков и нумерацией страниц. Дата отчета указывается по Москве; SHA-256 относится к проверенному тексту редактора в UTF-8, а не к байтам исходной кодировки файла на диске. Пример оформленного отчета: examples/foo-report.pdf.

Проверка ошибок и стандарта

Перед %prep обязателен разделитель # и 66 или более дефисов как последняя непустая строка перед секцией. Его отсутствие или изменение на строку, не соответствующую этому правилу, считается ошибкой (пункт 25.6).

Допустимы порядок с %files после сборки и пакетные блоки с %files до %prep. Этапы %prep → %build → %install → %check сохраняют порядок. Объявление и описание каждого подпакета предшествуют его списку файлов; смешивать списки до и после сборки в одном варианте spec нельзя. Подробные отличия от исходного документа описаны в пункте 25.7.

Непустое описание может повторять Summary. %changelog необязателен, но проверяется, если присутствует. Отсутствие %check, BuildRequires или %license отмечается как «Требует проверки» по исходникам и результатам сборки. Эти сведения не объявляются доказанными ошибками автоматически.

Проверяются порядок и обязательность секций/тегов, подпакеты и их описания, дублирование, баланс условий, типовые дефекты полей, пути без макросов, локали, development-файлы в runtime, changelog, опасные операции, отключение debug-пакетов и неподдерживаемые профилем теги/секции.

Статический анализ не раскрывает RPM-макросы и не запускает shell/Lua-код. Взаимоисключающие ветви условий различаются. Условия не вычисляются, поэтому архитектуры и варианты сборки требуют дополнительной проверки. Неизвестные дистрибутивные макросы помечаются для проверки, а не объявляются автоматически ошибочным синтаксисом.

Кнопка RPM-разбор дает проверку настоящим rpmspec с установленными макросами локальной ОС. Нужны rpmspec и bubblewrap (bwrap) на Linux. RPM может выполнять команды уже при раскрытии макросов, поэтому разбор всегда запускается в изоляции: без сети, домашнего каталога и записи в ОС. При отсутствии изоляции проверка отмечается как недоступная; обычный редактор продолжает работать. Исходники, файлы %include, макросы из домашнего каталога и внешние файлы %files -f в изоляцию не передаются: сообщения об их отсутствии нужно оценивать в целевой среде сборки. См. макросы RPM.

Воздействие на ОС

Во вкладке выберите все бинарные RPM одной сборки. Корень целевой ОС по умолчанию — /, то есть текущая система. Для другой ОС можно указать ее корневой каталог. При необходимости выберите buildroot сборки, затем нажмите «Проверить RPM и ОС». Нужна утилита rpm; пакет не устанавливается и его скриптлеты не запускаются.

Каждое замечание объясняет обнаруженную ситуацию, возможные последствия и рекомендуемое действие: например, какой установленный пакет уже владеет файлом и почему его замена может нарушить работу программы. Нажмите строку результата, чтобы прочитать пояснение и рекомендацию. Эти сведения и общий вывод о рисках также включаются в PDF. Потенциальный конфликт не означает доказанную несовместимость; неполное сравнение с ОС отмечается явно.

Проверка выявляет:

  • пути, принадлежащие другим пакетам в RPM-базе;
  • существующие целевые файлы, не принадлежащие пакетам по RPM-базе;
  • конфиги без config(noreplace) и настройки устройств/ядра/загрузки;
  • особые права, capabilities, нестандартных владельцев и рискованные скриптлеты;
  • пересечения состава выбранных RPM;
  • каталоги buildroot, владение которыми надо подтвердить через %dir или зависимость;
  • файлы и символические ссылки buildroot, не вошедшие ни в один выбранный RPM.

Обычное обновление того же пакета и общие каталоги не считаются конфликтами. Совпадение пути с другим пакетом — потенциальный конфликт; окончательный результат транзакции зависит также от Provides/Obsoletes, содержимого и RPM. При отсутствии или недоступности RPM-базы вывод явно сообщает, что сравнение не выполнено. Файлы без владельца в RPM-базе и файлы без пользователя/группы в заголовке RPM проверяются отдельно.

Buildroot не обходится по символическим ссылкам. Файлы лицензии/документации могут добавляться RPM после %install, поэтому их отсутствие в раннем buildroot отмечается для проверки. RPM-результаты относятся к выбранным бинарным пакетам; изменения в редакторе попадут в RPM только после пересборки.

Проверка не доказывает все эффекты произвольных скриптов и не заменяет чистую сборку, проверку лицензии/ABI/зависимостей и испытание установки в отдельной ОС. rpmlint следует запускать в целевой среде и разбирать его замечания; само приложение не запускает rpmlint для открытого spec. В приложении эти ограничения видны во вкладке «Стандарт и охват».

Командная строка

python3 -m spec_checker --check examples/foo.spec
python3 -m spec_checker --check examples/foo.spec --native --json
python3 -m spec_checker --check examples/foo.spec --pdf /path/foo-report.pdf
python3 -m spec_checker --check /path/foo.spec \
  --rpm /path/foo.rpm --rpm /path/foo-devel.rpm \
  --root / --buildroot /path/buildroot --json

Коды выхода: 0 — обнаруженных ошибок нет (предупреждения и ревью возможны), 1 — есть ошибки, 2 — файл/профиль/внешняя операция недоступны. При --rpm система также сравнивается с / по умолчанию; --root позволяет выбрать другой корень.

Профиль по умолчанию находится в spec_checker/default_policy.json. Для согласованных изменений репозиторных правил скопируйте его в собственный JSON и запустите python3 run.py --profile /path/profile.json. Локальная конфигурация rpmlint может предъявлять дополнительные требования. Такие расхождения нужно оценивать по правилам репозитория. Group разрешен текущим профилем МосТех.ОС по подтвержденным примерам пакетов.

Проверка проекта

python3 -m unittest discover -s tests -v
python3 tools/integration_smoke.py
python3 tools/gui_smoke.py
python3 tools/kde_dialog_smoke.py

Модульные тесты проверяют диагностику, условные ветви, подпакеты, сохранение и аудит состава. Интеграционная проверка требует RPM tools и bubblewrap, создает тестовый RPM во временном каталоге и читает RPM-базу текущей ОС. GUI-проверка требует доступного дисплея и использует временный spec-файл. Проверка KDE требует kdialog, xwininfo и X11/XWayland; она открывает собственные тестовые окна и проверяет выбор, отмену, несколько файлов и сохранение, сохраняя отзывчивость приложения.