[devel] task build

[devel] task build

[Led]

А какие причины того, что task'и по сборке пакетов работают ТОЛЬКО 
последовательно?

И, кстати, сборка производится всё ещё с принудительным "--nprocs 1"? Почему?

-- 
Led

Re: [devel] task build

[Alexey Tourbin]

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

On Thu, Feb 19, 2009 at 11:41:03AM +0200, Led wrote:
> А какие причины того, что task'и по сборке пакетов работают ТОЛЬКО 
> последовательно?

А в каком порядке их следовало бы обрабатывать?

> И, кстати, сборка производится всё ещё с принудительным "--nprocs 1"? Почему?

Чтобы получить хороший лог сборки.  При nprocs более 1 в логе сборки
вывод разных команд обчно перемешивается случайным/нерегулярным образом.

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

Re: [devel] task build

[Led]

On Thursday, 19 February 2009 11:47:22 Alexey Tourbin wrote:
> On Thu, Feb 19, 2009 at 11:41:03AM +0200, Led wrote:
> > А какие причины того, что task'и по сборке пакетов работают ТОЛЬКО
> > последовательно?
>
> А в каком порядке их следовало бы обрабатывать?

Параллельно

>
> > И, кстати, сборка производится всё ещё с принудительным "--nprocs 1"?
> > Почему?
>
> Чтобы получить хороший лог сборки.  При nprocs более 1 в логе сборки
> вывод разных команд обчно перемешивается случайным/нерегулярным образом.

И ради этой сомнительно-полезной "красивости" тратить 2 часа на сборку пакета 
вместо 20-30 минут? Забавно...

-- 
Led

Re: [devel] task build

[Alexey Tourbin]

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

On Thu, Feb 19, 2009 at 11:52:44AM +0200, Led wrote:
> On Thursday, 19 February 2009 11:47:22 Alexey Tourbin wrote:
> > On Thu, Feb 19, 2009 at 11:41:03AM +0200, Led wrote:
> > > А какие причины того, что task'и по сборке пакетов работают ТОЛЬКО
> > > последовательно?
> >
> > А в каком порядке их следовало бы обрабатывать?
> Параллельно

А как потом сводить?  Если задать жесткие условия сериализации,
то при параллельной сборке N заданий придётся заново пересобирать
остальные N-1 заданий.

А более или менее жесткие условия сериализации нужны для проверки
целостности: мы переводим репозитарий из состояния S_k (текущего)
в состояние S_{k+1} (новое).  Нельзя переводить репозитарий сразу
в несколько новых состояний.  Поскольку возможна интерференция между
новыми состояниями.

> > > И, кстати, сборка производится всё ещё с принудительным "--nprocs 1"?
> > > Почему?
> >
> > Чтобы получить хороший лог сборки.  При nprocs более 1 в логе сборки
> > вывод разных команд обчно перемешивается случайным/нерегулярным образом.
> 
> И ради этой сомнительно-полезной "красивости" тратить 2 часа на сборку пакета 
> вместо 20-30 минут? Забавно...

Лог сборки будет храниться, а при тестовой пересборке -- обновляться.
Короче, должна быть опредлённая структура, которая фиксирует все
изменения пакетов, как "фактические" изменения (когда заливают новую
версию), так и "тестовые" (когда идет тестовая пересборка существующих
пакетов).

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

Re: [devel] task build

[Led]

On Thursday, 19 February 2009 12:17:46 Alexey Tourbin wrote:
> On Thu, Feb 19, 2009 at 11:52:44AM +0200, Led wrote:
> > On Thursday, 19 February 2009 11:47:22 Alexey Tourbin wrote:
> > > On Thu, Feb 19, 2009 at 11:41:03AM +0200, Led wrote:
> > > > А какие причины того, что task'и по сборке пакетов работают ТОЛЬКО
> > > > последовательно?
> > >
> > > А в каком порядке их следовало бы обрабатывать?
> >
> > Параллельно
>
> А как потом сводить?  Если задать жесткие условия сериализации,
> то при параллельной сборке N заданий придётся заново пересобирать
> остальные N-1 заданий.

Что "сводить"? Задания сами по себе друг от друга не зависят (?). если 
какие-то пакеты зависят от последовательности сборки, то они находятся в 
одной task (а внутри task'а уже пакеты собираются последовательно)

>
> А более или менее жесткие условия сериализации нужны для проверки
> целостности: мы переводим репозитарий из состояния S_k (текущего)
> в состояние S_{k+1} (новое).  Нельзя переводить репозитарий сразу
> в несколько новых состояний.

Переводить - последовательно. А собирать (в смысле - выполнять сборочные 
task'и) - параллельно.

> Поскольку возможна интерференция между 
> новыми состояниями.
>
> > > > И, кстати, сборка производится всё ещё с принудительным "--nprocs 1"?
> > > > Почему?
> > >
> > > Чтобы получить хороший лог сборки.  При nprocs более 1 в логе сборки
> > > вывод разных команд обчно перемешивается случайным/нерегулярным
> > > образом.
> >
> > И ради этой сомнительно-полезной "красивости" тратить 2 часа на сборку
> > пакета вместо 20-30 минут? Забавно...
>
> Лог сборки будет храниться, а при тестовой пересборке -- обновляться.
> Короче, должна быть опредлённая структура, которая фиксирует все
> изменения пакетов,

Т.е. git для "фиксации изменения пакетов" - недостаточен?

> как "фактические" изменения (когда заливают новую 
> версию), так и "тестовые" (когда идет тестовая пересборка существующих
> пакетов).

Не вижу причин считать "тестовые пересборки" Священной коровой. ИМХО 
полезность и самодостаточность "тестовых пересборок" сильно преувеличена: 
неоднократно натыкался на случаи, когда после формально успешной пересборки 
пакет не то что не работал, а даже не устанавливался (в частности, из-за 
изменившихся автоматически полученных Require'ов).

-- 
Led

Re: [devel] task build

[Dmitry V. Levin]

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

On Thu, Feb 19, 2009 at 01:17:46PM +0300, Alexey Tourbin wrote:
> On Thu, Feb 19, 2009 at 11:52:44AM +0200, Led wrote:
> > On Thursday, 19 February 2009 11:47:22 Alexey Tourbin wrote:
> > > On Thu, Feb 19, 2009 at 11:41:03AM +0200, Led wrote:
> > > > А какие причины того, что task'и по сборке пакетов работают ТОЛЬКО
> > > > последовательно?
> > >
> > > А в каком порядке их следовало бы обрабатывать?
> > Параллельно
> 
> А как потом сводить?  Если задать жесткие условия сериализации,
> то при параллельной сборке N заданий придётся заново пересобирать
> остальные N-1 заданий.

Мне _кажется_, что вероятность того, что придётся пересобирать остальные
задания из-за изменения сборочной среды, невелика.  С другой стороны, у
нас пока не так много вероятных параллельных заданий, мы хотим нагрузить
сборочную систему дополнительными проверками, и на всё на это надо
много сборочных ресурсов.


-- 
ldv

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

Re: [devel] task build

[Dmitry V. Levin]

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

On Thu, Feb 19, 2009 at 12:37:19PM +0200, Led wrote:
> On Thursday, 19 February 2009 12:17:46 Alexey Tourbin wrote:
[...]
> > как "фактические" изменения (когда заливают новую 
> > версию), так и "тестовые" (когда идет тестовая пересборка существующих
> > пакетов).
> 
> Не вижу причин считать "тестовые пересборки" Священной коровой. ИМХО 
> полезность и самодостаточность "тестовых пересборок" сильно преувеличена: 

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

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

тестов никогда не бывает достаточно.


-- 
ldv

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

Re: [devel] task build

[Led]

On Thursday, 19 February 2009 14:56:27 Dmitry V. Levin wrote:
> On Thu, Feb 19, 2009 at 01:17:46PM +0300, Alexey Tourbin wrote:
> > On Thu, Feb 19, 2009 at 11:52:44AM +0200, Led wrote:
> > > On Thursday, 19 February 2009 11:47:22 Alexey Tourbin wrote:
> > > > On Thu, Feb 19, 2009 at 11:41:03AM +0200, Led wrote:
> > > > > А какие причины того, что task'и по сборке пакетов работают ТОЛЬКО
> > > > > последовательно?
> > > >
> > > > А в каком порядке их следовало бы обрабатывать?
> > >
> > > Параллельно
> >
> > А как потом сводить?  Если задать жесткие условия сериализации,
> > то при параллельной сборке N заданий придётся заново пересобирать
> > остальные N-1 заданий.
>
> Мне _кажется_, что вероятность того, что придётся пересобирать остальные
> задания из-за изменения сборочной среды, невелика.  С другой стороны, у
> нас пока не так много вероятных параллельных заданий, мы хотим нагрузить
> сборочную систему дополнительными проверками, и на всё на это надо
> много сборочных ресурсов.

Ну... тогда понятно (если ресурсы не простаивают). Спасибо.

-- 
Led

Re: [devel] task build

[Alexey Tourbin]

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

On Thu, Feb 19, 2009 at 03:56:27PM +0300, Dmitry V. Levin wrote:
> > > > А в каком порядке их следовало бы обрабатывать?
> > > Параллельно
> > 
> > А как потом сводить?  Если задать жесткие условия сериализации,
> > то при параллельной сборке N заданий придётся заново пересобирать
> > остальные N-1 заданий.
> 
> Мне _кажется_, что вероятность того, что придётся пересобирать остальные
> задания из-за изменения сборочной среды, невелика.

Это сложно реализовать на шелле хорошо.
Например, для сборки одного пакета нужна такая операция:

1) lock /ALT/Sisyphus
2) run hsh-rebuild
3) wait until hsh-rebuild installs BuildRequires
4) release /ALT/Sisyphus lock ASAP

То есть надо уметь обкладывать локами и уметь эти локи вовремя снимать,
иначе пакет может просто не собраться по независящим от него причинам.

Хешер не шибко модульный, чтобы в него можно было вклиниться, и вообще
весь этот юниксвей в этом смысле не шибко модульный.

> С другой стороны, у
> нас пока не так много вероятных параллельных заданий, мы хотим нагрузить
> сборочную систему дополнительными проверками, и на всё на это надо
> много сборочных ресурсов.

В принципе заманчиво повысить "время отклика" системы, чтобы всем не
приходилось долго ждать, если кто-то один застрял.  Но это сложно
сделать хорошо.

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

Re: [devel] task build

[Mikhail Gusarov]

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


Twas brillig at 16:18:17 20.02.2009 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> Это сложно реализовать на шелле хорошо.
 AT> Например, для сборки одного пакета нужна такая операция:

 AT> 1) lock /ALT/Sisyphus
2-3) сделать теневую копию сизифа (хардлинками)
 AT> 4) release /ALT/Sisyphus lock ASAP
5) собирать, сколько влезет.

-- 

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

Re: [devel] task build

[Alexey Tourbin]

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

On Fri, Feb 20, 2009 at 07:25:26PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 16:18:17 20.02.2009 UTC+03 when at@altlinux.ru did gyre and gimble:
> 
>  AT> Это сложно реализовать на шелле хорошо.
>  AT> Например, для сборки одного пакета нужна такая операция:
> 
>  AT> 1) lock /ALT/Sisyphus
> 2-3) сделать теневую копию сизифа (хардлинками)
>  AT> 4) release /ALT/Sisyphus lock ASAP
> 5) собирать, сколько влезет.

Это не серьезно, если брать проблему в общем виде.

Нам надо взять лок и отпустить лок, в определенные моменты времени.
В перле (или в окамле, или в коммон-лиспе) это ровно два системных
вызова; можно просто сделать callback slots, чтобы дёргалось когда
надо что надо.  В шелле find-grained locking делать более-менее нельзя;
прежде всего потому, что locking существует на уровне отдельно взятого
процесса, а основной способ организации вычислений на шелле -- это
порождение новых процессов.  А какие могут быть коллбеки между
процессами.

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

Короче, программирование на шелле in large -- это более-менее не серьезно.
Правда, на шелле обычно получается писать более лаконичный код (чем на
перле).  Но также код на шелле более уязвим к нетипичным ситуациям,
потому что там нет настоящих структур данных, а всё делается набором
"инструментов", которые на самом деле являются хаками.

Короче, то, чем мы занимаемся -- это всё более-менее сосёт.
"Я его слепила из того что было" и т.д.

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