On Thu, Aug 30, 2007 at 07:54:19PM +0400, Dmitry V. Levin wrote:
> Если пренебречь всякими provides/obsoletes, то можно предложить такую
> проверку:

Ими нельзя пренебрегать.  Кто-то обязательно напишет
Provdies: coreutils, Obsoletes: coreutils.

> Проверяются права согласно имени собранного srpm-пакета.
> Кроме того, для каждого собранного бинарного пакета,
> если бинарный пакет с таким именем уже есть в репозитории, то
> проверяются права согласно имени соответствующего ему srpm-пакета.
> 
> Поясню на примере.  Если ты отправляешь на сборку тэг, из которого
> собирается srpm-пакет по имени foobar и бинарный пакет по имени
> glibc-core, то результат сборки будет пропущен только если ты можешь
> публиковать foobar И glibc.

Я об этом тоже думал.  Это уже следующий этап -- формирование временного
сизифа и проверка, удаётся ли "прописать" новые пакеты в этот временный
сизиф без "конфликтов".

Но сейчас у нас предыдущая задача: определить, собрался пакет или не
собрался, и собрался ли он достаточно хорошо, а то надо сразу давать
ему reject.  Конекст этой задачи по пакетам ограничен содержимым
билдурта при сборке.  По сути мы пока не знаем, в какой репозитарий
собранные пакеты придётся "прописывать".  Сейчас пока нужно выяснить,
собирается ли пакет САМ ПО СЕБЕ, и является ли результат в принципе
публикуемым (наследование коммитов, синхронизация архитектур,
идентичность noarch пакетов).

Что до проверки ACL, то её можно делать раньше или позже.  Более того,
нет ничего плохого в том, чтобы делать её немного попозже.  Ведь любой
пакет, который не проходит ACL, является потенциальным NMU.  Значит, у
нас получается "цимесная" модель NMU вместо старой "отстойной".  Можно
будет выдавать NUM per commit и только per-commit, то есть
"подтверждать" NMU с предварительной проверкой.  Думаю, что правом
подтверждения NMU можно наделить и "ответственного товарища", поскольку
часто речь идёт о NMU типа "rebuild with libxxx.so.2".