[devel] BTE
Alexander Bokovoy
=?iso-8859-1?q?a=2Ebokovoy_=CE=C1_sam-solutions=2Enet?=
Вт Дек 10 19:35:10 MSK 2002
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.
Подробная информация о списке рассылки Devel