Re: [devel] BTE

[Alexander Bokovoy <a.bokovoy@sam-solutions.net>]

On Tue, Dec 10, 2002 at 07:00:20PM +0300, AntonFarygin wrote:
> >2. Высокий уровень безопасности используемых для достижения (1) средств.
> >3. По возможности единообразные алгоритмы для выполнения одинаковых задач
> >  в разных процессах.
> >4. Единая система сборки всех категорий результирующих продуктов -- от
> >  отдельных пакетов и репозитариев до ISO-образов, содержащих
> >  конкретные решение ("устанавливаемые дистрибутивы", "системы для
> >  запуска прямо с CD" и так далее).
> >5. Единая система контроля качества всех категорий результирующих 
> >продуктов.
> >
> Пункт 5 - единый с чем именно? Не понимаю...
Единая со всей остальной системой (BTS, project management, сборочной
средой). Потому что контроль качества -- это не только проверка на
устанавливаемость пакетов, это и feedback, и соответствующие блокировки
выполнения задач в проекте.

> >системы, дополнений, etc), выполнение которых должно происходить
> >идентично, насколько это возможно.
> >
> Согласен со всем, кроме пункта 1. Ибо, на мой взгляд, в сборочной среде 
> не должно присутствовать:
> a) по возможности установленных сервисных программ
Ты имеешь в виду тех, что ставят себя в init.d?

> б) по возможности _запущенных_ сервисных программ. Например - на данный 
> момент процесс N 1 обламывается на этапе установки пакета apache на 
> скрипте добавления chkconfig --add httpd (что естественно). Да и не 
Неестественно.

> совсем понятно - почему для apache-devel необходим пакет apache ??? 
> Разве нельзя пакеты собирать, не имея реальных сервисов в системе, а 
> имея только библиотеки?
В случае apache надо рассматривать подробнее (я не помню прямо сейчас).
Однако я не понимаю, почему chkconfig --add httpd должен что-то ломать --
ведь при выполнении этой команды ничего реально не запускается, только
делается symlink.

> Все остальные среды, несомненно, должны эмулировать реальную систему.
> 
> Причина, побудившая выполнять создание сборочной среды под обычным 
> пользователем - в первую очередь безопасность. Не стоит забывать, что  у 
> нас сейчас будет открываться доступ к сборочным серверам через почтовый 
> интерфейс. И, честно говоря, давать возможность создавать рутовые чруты 
> по письму (пусть даже авторизованному) - страшно.
Страшно -- помести "исполнителя" в UML. Это вопрос deployment
соответствующей службы, а не ее реализации. Вот cvs и shell не
предоставляют достаточных средств для защиты, а devel.altlinux.ru тем не
менее серьезно защищен.

> >Та реальность, которую ты предлагаешь считать "не хуже других", не
> >позволяет обеспечить идентичную реализацию одинаковых подпроцессов. Более
> >того, исходя из развернутого разговора с AVN, данная реальность не
> >предполагает одинакового поведения при сборке всех пакетов, что неумолимо
> >ведет к рождению исключений. Я считаю это серьезной ошибкой в
> >проектировании.
> >
> Можно поподробнее про неодинаковое поведение?
> Поведение сборочной среды диктуется исключительно зависимостями пакета и 
> возможностью указывать другой apt репозиторий.
Этот вопрос я переадресую AVN, поскольку он и вел речь про неодинаковое
поведение.


-- 
/ Alexander Bokovoy
---
When does summertime come to Minnesota, you ask?  Well, last year, I
think it was a Tuesday.