гм. для начала вопрос по 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