On Mon, Jun 16, 2008 at 02:03:40AM +0400, Dmitry V. Levin wrote:
> > Вообще идея раннего ACL в связи с предложенным означает слишком
> > диаметральное рсслоение -- либо априорное доверие, либо априорное
> > недоверие.  На практике же доверие -- штука тонкая, "доверяй но
> > проверяй".  Хотелось бы иметь механизм подтверждения (или отмены)
> > "неавторизированных" сборок вопреки ACL.  А именно, хочется, чтобы
> > неавторизированную сборку можно было "быстро подтвердить" или же,
> > наоборот, "быстро отшить".
> 
> Насколько быстрым?  Как ты это видишь?

Я это вижу так: ACL должен проверяться не на входе, а на выходе.
Если пакет собрался, тогда есть о чём говорить.  Формируется список
"нарушений" пакета.  Одно из нарушений -- не проходит проверка по ACL;
другое нарушение -- появление новых анметов.

Нарушение ACL соответствует ситуации NMU.  Мы можем дать разовое NMU
без изменения ACL, но для этого нужно точно знать изменения в пакете
(то есть пакет должен собраться).  Тогда либо maintainer пакета,
либо арбитр (если maintainer недоступен) может сказать "SKIP ACL OK".

> > Mainatiner не всегда может быстро среагировать, поэтому нужен арбитр.
> Кто же за мантейнера сможет определить, пропускать сборку или нет?

Необходимость в NMU может быть неизбежной, и во многих случаях NMU
легко проверить, если там небольшие изменения.  Например, при пересборке
пакетов с новым soname'ом.  Кто собрал новый soname, тот может
попытаться делать NMU на зависящие пакеты.  Сейчас так и происходит
(напр. libdb4.7), просто арбитр действует закулисно и в обход системы.
А можно сделать саму систему достаточно гибкой и прозрачной.