[devel] Re: P: разделение критичности проверок для base..contrib (was: RFC: test-libs)

[Alexey Tourbin]

On Thu, Jun 16, 2005 at 08:16:16AM +0300, Michael Shigorin wrote:
> > У нас RPM выполняет несколько несвойственные ему функции
> > (policy enforcement).  Это примерно как если бы gcc по
> > умолчанию работал в режиме -Wall -Werror.  Не знаю, хорошо это
> > или плохо. :)
> 
> Это плохо постольку, поскольку полиси в существенной степени
> нигде не зафиксированы.

Полиси пусть kirill@ пишет. :)

> 	При этом на существенно разные по критичности и
> 	поддерживаемости компоненты Sisyphus налагаются
> 	одинаковые требования.  Выходит прокрустово ложе.

Это "проходные" требования снизу.  Требования сверху ограничены только
фантазией maintainer'а.  Предлагается установить достаточно высокую
планку прохождения пакетов в сизиф.  И время от времени её поднимать.
Будет встряска от застоя. :)

> Есть предложение обязать вводящих полиси фиксировать их хотя бы
> на том же wiki, если не в документации пакета, который выполняет
> проверку и/или enforcement; если Sisyphus собирается

Есть языковая проблема: если в рассылках словечки типа "слинковаться" --
это techspeak, то для документации это уже не катит.  Может по-английски
полиси писать?  Будет одно серьезное преимущество: весь остальной мир
узнает, какие у нас здесь ценные идеи бродят. :)

> масштабироваться (а как общественный проект -- он обязан быть
> достаточно разным), следует реализовать различие критичности
> проверок для различных компонент.

Проверка ELF'ов достаточно критична.  Некритичные компоненты должны
быть noarch -- с них и спросу никакого нет.

По поводу масштабирования, субъективное мнение: никакого масштабирования
в ближайшем будущем не будет, лучше попытаться всеми силами вырваться
вперед.  Грубо говоря, чтобы на вопрос "чем это лучше Fedora Core" можно
было с чистой совестью ответить: "всем" (это, кстати, предписывает
следить за pserver:anonymous на cvs.fedora.redhat.com:/cvs/dist :).

Вперёд можно вырваться только за счет технологического превосходства.

> Есть мнение, что часть этих работ уже выполнена в рамках проектов
> incominger и prometeus, при этом (похоже) имела место некоторая
> дубликация.  Хорошо бы помочь их авторам скоординироваться и/или
> интегрировать код.

Подробнее: какой именно код дублируется?

> Дим, а может, пора ALT начинать не толстеть, а взрослеть и для
> начала всё те же правила игры публиковать?  А то забава
> раскладыванием подводных грабель -- штука такая,
> посмешит-посмешит да и надоест.

Для RPM нужен legacy mode -- чтобы при сборке пакетов в частном
порядке не приходилось вникать в особенности ALT полиси.

Более серьезная претензция как раз по части .la файлов -- не собираются
KDE'шные приложения без хака на configure и т.п.  Если совместимости на
уровне RPM никто не гарантировал, то несовместимость на уровне GNU
autotools -- это уже некий показатель.

> Дистрибутив с невнятным позиционированием не может быть успешен
> коммерчески и не может быть интересен как платформа.

Долой дистрибутивы!  Даешь альтернативный формат выпуска свободного
софта!

> Проект с неявными правилами неприемлемости работы участников
> обречён на маргинализацию и участь цехов.

Проект и так уже маргинализован, один из кругов маргинализации
(маргинальности?) -- языковой.  С другой стороны, маленькие проекты
легче поддаются встряске.

> PS: рекомендую _прочитать_ вчерашнюю ссылку на newsforge и
> подумать про перфекционизм.  Он уместен разве что в SRPMS.perfect.
> :)

Да прочитал.  Вот несколько ошибок мы вчера нашли -- это хорошо или
плохо?  Например, нерабочий libnss_wins.  Это какую пользовательскую
базу нужно иметь, чтобы дождаться от тестеров-волонтёров
квалифицированного багрепорта по этому поводу?  И какая у нас
пользовательская база имеется и сколько тестеров-волонтёров тестируют
в репозитарии специфические фичи.  Очень важный вопрос.

Так вот, просто предлагается ликвидировать целый класс потенциальных
ошибок.  Перфекционизм это или нет, я не знаю.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20050616/72f09c52/attachment-0001.bin>