Re: [devel] Угрозы развитию дистрибутива. Пути решения.

["Денис Смирнов" <mithraen@freesource.info>]

[-- Attachment #1: Type: text/plain, Size: 5029 bytes --]

On Mon, Oct 03, 2011 at 01:11:32PM +0400, Paul Wolneykien wrote:

PW>    Вообще говоря, мне кажется, что это проблема не отдельных пакетов, не 
PW> cronbuild, а всего Сизифа в целом. То, что нет пересборки по 
PW> зависимостям. 

А она далеко не всегда нужна. После обновления, скажем, gcc нет
необходимости пересобирать _все_, от чего зависит gcc.

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

PW> Точнее, это не проблема даже, а просто особенность  поведения.

Я не представляю себе как эту проблему можно решить.

PW> Частично неблагоприятные последствия компенсируются тем, что 
PW> Сизиф регулярно пересобирается весь целиком. 

Это не так. Это исключительно тестовые пересборки, их результат не
попадает в Сизиф. У нас до сих пор есть пакеты без debuginfo, например.

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

Для этого тоже есть робот от viy@, который я и использую для выстраивания
порядка сборки модулей ghc.

PW>    Посему предлагаю поднять вопрос о добавлении в Сизиф/girar 
PW> возможности создавать некоторые «правила пересборки подсистем». Так, 
PW> чтобы пользователь мог указать, в каком порядке должно пересобираться 
PW> некоторое подмножество пакетов в рамках процедуры регулярной пересборки 
PW> Сизифа. Тогда не придётся ничего прикручивать к cronbuild.

Увы, это не так.

Поясняю -- вот cronbuild пытается пересобрать asterisk. Необходимо
обязательно _в той же транзакции_ пересобрать модули. С чего это girar
должен чего-то додумывать, и добавлять в транзакцию пакеты, которые его не
просили?

Это совершенно недопустимо. Низкоуровневые решения должны выполнять четко
команды, а не пытаться добавлять к ним свой интеллект. А имитировать
мышление, это уже дело для роботов, которые работают поверх girar. Таких
как cronbuild.

А уж с ghc все еще грустнее -- надо учитывать тот факт, что обновление
одного модуля может потребовать обновить другой. А может и не потребовать.
И это надо иногда даже тестировать -- делая пробные сборки. И робот,
который сможет сам мантейнить ghc должен быть весьма умный. Я бы очень
хотел чтобы такой был, но не думаю что столь умного робота кто-нибудь
станет писать :)

А вот с перловыми модулями все куда легче. Робот там справится, хотя его
деятельность может привести к временному нарушению пересобираемости других
пакетов (обновился модуль -- пакет несовместимый с новой версией больше не
собирается и не работает).

Так что поддержку перловых модулей можно хоть сейчас передать на
растерзание роботам.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]