В Сизифе есть две системы проверки пакетов: sisyphus_check и repocop. Понятно что основной "движитель" каждого из проектов работает в разной среде и занимается немного разнымим задачами, но вот сами проверки сильно пересекаются. Очень приятно было бы при попадании пакета в incoming проверять его по тем же параметрам, по которым потом его проверяют уже в репозитарии. А посему. Я предлагаю сделать единый формат "тестов" между sisyphus_check и repocop. Единственное пожелание, чтобы "тесты" можно было писать на shell, а остальное - не важно. Со стороны sisyphus_check думаю не будет препятствий. Добавляю в CC legion и ldv.
гм. для начала вопрос по sisyphus_check. он что, не использует содержимое пакета, а только значения полей в RPM header?
также хочу ясно понимать. какие внешние данные/ресурсы нужны sisyphus_check для выполнения?
(In reply to comment #1) > он что, не использует содержимое пакета, а только > значения полей в RPM header? Тот sisyphus_check, что, возможно, стоит у вас в системе использует только их. Остальные компоненты использовать в хост системе не безопасно. (In reply to comment #2) > также хочу ясно понимать. > какие внешние данные/ресурсы нужны sisyphus_check для выполнения? Никаких, кроме rpm и базовых утилит... даже утилита file не используется из-за небезопасности. То что делает sisyphus_check в хост системе не важно. sisyphus_check сейчас расширяется проверками. Интерфейс очень прост. Можно сделать пакет, который добавляет к стандартным проверкам ещё и проверки из repocop. Вот только вопрос, насколько эти дополнительные проверки будут безопасны и можно ли использовать их для пакетов, в котором есть зловредный код.
понял, спасибо. > Можно сделать пакет, который добавляет к > стандартным проверкам ещё и проверки из repocop. В действительности сейчас их проще при необходимости портировать (т.е. переписывать заново :(). например, вот тест, который я вчера добавил: ----- #!/bin/sh sqlite3 "$REPOCOP_TEST_TMPDIR/tmp.db" <<EOSQL attach database '$REPOCOP_TEST_DBDIR/rpm.db' as rpm; .mode tabs .output $REPOCOP_TEST_TMPDIR/msg select distinct rpm_requires.pkgid from rpm_requires where requirename glob 'j2se*'; EOSQL for i in `cat $REPOCOP_TEST_TMPDIR/msg`; do repocop-test-warn -k $i "Old java provides of j2se-* are deprecated and can be removed any time. Please, use Requires: java (>= version) syntax."; done rm $REPOCOP_TEST_TMPDIR/* ----------------------- переписывается для sisyphus_check он очевидным образом, но пускать его как есть бессмысленно: он тянет за собой sqlite. отсюда вывод: задача сделать пакет, который добавляет к стандартным проверкам ещё и проверки из repocop, некорректна из-за существенной разницы в требованиях к ним.
> Можно сделать пакет, который добавляет к > стандартным проверкам ещё и проверки из repocop. на мой взгляд, осмысленна обратная задача: пускать sisyphus_check через repocop. IMHO, следующая ситуация имеет смысл: Допустим написана новая проверка под sisyphus_check. Тогда прогнав ее под repocop, получим список пакетов, затронутых проверкой, майнтайнеры могут посмотреть новый тест заранее и высказаться за или против переноса его в основной набор тестов.
я написал пускатель sisyphus_check под repocop. Первый вывод - не все тесты надо запускать. вот типичный пример. $ sisyphus_check --verbose --files /home/repocop/Sisyphus/files/noarch/RPMS/pngbook-1.0-alt1.noarch.rpm /home/repocop/Sisyphus/files/noarch/RPMS/pngbook-1.0-alt1.noarch.rpm: rpmsign failed sisyphus_check: check-gpg ERROR: package signatures violation grep: /usr/lib/rpm/*-files.req.list: No such file or directory check-gpg был явно лишний. подводя итоги: похоже sisyphus_check надо серьезно порезать. тесты нужно выделить отдельно, и не в один пакет, а хотя бы в 3: tests-genertic общего характера (например, могут применяться в Etersoft для проверки своих приватных пакетов) tests-sisyphus sisyphus specific tests-experimental (не запускаются в incoming)
сильно захламлен результат :( [repocop@repocop by-test]$ wc -l sisyphus_check.txt 310 sisyphus_check.txt [repocop@repocop by-test]$ grep -v gpg sisyphus_check.txt | wc -l 48
(In reply to comment #6) > я написал пускатель sisyphus_check под repocop. > > Первый вывод - не все тесты надо запускать. > вот типичный пример. Все проверки в sisyphus_check обязательны к исполнению. Это базовый инструмент и должен работать всегда. Даже если пакет будет разделён, то утилита будет требовать все подпакеты. Тогда зачем делить? Если есть в этом пакете есть баги, то их нужно исправлять. > check-gpg был явно лишний. Почему лишний? Все пакеты должны быть подписаны.
Тут тонкость в том, что есть как технология Sisyphus, так и репозиторий Sisyphus, и непонятно, к чему sisyphus в sisyphus_check относится. Если к технологии, то часть тестов опциональная. Если к репозиторию - то все обязательны. Так что вопрос можно переформулировать: сделать отдельный НЕСИЗИФ-check, в который войдёт всё, что не относится к проверкам, интересным исключительно в контексте incoming (скажем, проверка buildhost или майнтайнерского мыла), и sisyphus_check, в который войдут проверки НЕСИЗИФ-check и дополнительные, инкамингерские.
(In reply to comment #9) +1
> > check-gpg был явно лишний. > Почему лишний? Все пакеты должны быть подписаны. Пакет то в Сизифе :) Значит, он подписан. Просто ключ устарел, наверное...
(In reply to comment #9) > Если к технологии, то часть тестов опциональная. Если к репозиторию - то все > обязательны. Как я уже говорил, все проверки должны проходить для пакета, направленного в сизиф. Он относится к репозитрию. (In reply to comment #11) > Значит, он подписан. Просто ключ устарел, наверное... Это бага в пакете alt-gpgkeys. Раньше у нас не было полиси (кстати, сейчас тоже нет) по удалению из репозиторию пакетов, которые не поддерживаются и не чинятся под новые проверки (читайте: правила репозитория).
IMHO, предмет обсуждения пересекся с #15376 от Etersoft
в общем, я выкрутился с текущим sisyphus_check: sisyphus_check --no-check-gpg --no-check-buildhost --no-check-buildtime
