[devel] Распараллеливание incoming.

[devel] Распараллеливание incoming.

[Igor Vlasenko]

Несколько в сторону, по поводу incoming.

DVL> Если кому-то нужно устроить continuous integration для каких-то проектов,
DVL> то [...] сборочница вряд ли справится с такой нагрузкой.

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

Это поведение является защитой от появления unmets.
Но надо понимать, что это достаточная защита, но, на самом деле,
не необходимая.

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

Почему так? Трюк здесь в том, что у этих пакетов зависимости новой версии
и старой версии не отличаются.

Поэтому для такого класса пакетов сборку можно оптимизировать.
Если мы собрали пакет, и оказалось, что 
- его requires зависимости не изменились,
то 
1) пересобирать такой пакет уже не нужно, пусть Сизиф себе обновляется,
тесты останутся релевантными.
2) если при этом на provides такого пакета нет жесткой зависимости,
вида = или =set:
то такой пакет обладает свойством, что он не мешает сборке других пакетов.
Т.е. если во время сборки другого пакета B в Сизифе обновился пакет C из сборочного окружения В, и у этого С зависимости инвариантны,
то при сборке и тестировании В на обновление пакета С 
можно не обращать внимания. Unmets не будет.

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

имело бы смысл сборочнице распознавать такие пакеты.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Распараллеливание incoming.

[Dmitry V. Levin]

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

On Sat, Nov 26, 2011 at 12:58:46PM +0200, Igor Vlasenko wrote:
> Несколько в сторону, по поводу incoming.
> 
> DVL> Если кому-то нужно устроить continuous integration для каких-то проектов,
> DVL> то [...] сборочница вряд ли справится с такой нагрузкой.
> 
> Как я понимаю, наша сборочница устроена так, что если по окончанию 
> сборки пакета его сборочное окружение успело измениться, пакет 
> посылается на сборку еще раз.
> Это означает, что увеличение числа параллельных потоков
> сборки может даже замедлить incoming, так как потоки вместо 
> сборки новых пакетов будут заниматься постоянной пересборкой старых.

Масштабирование сборочницы по числу параллельных потоков когда-нибудь
решит эту проблему.

> Это поведение является защитой от появления unmets.
> Но надо понимать, что это достаточная защита, но, на самом деле,
> не необходимая.
> 
> Для многих пакетов, те же moodle*-lang-* пакеты, к примеру,
> такое поведение не нужно. 
> Для таких пакетов заведомо ничего страшного не случится,
> если они будут собраны на позавчерашнем сизифе, проверены на устанавливаемость
> на вчерашнем сизифе, включены в сегодняшний сизиф.
> 
> Почему так? Трюк здесь в том, что у этих пакетов зависимости новой версии
> и старой версии не отличаются.

Какая разница, чем вызвано изменение сборочной/установочной среды,
отличиями в зависимостях между старой и новой версией пакета, или
изменениями в сизифе?  Какой смысл проводить глабальные проверки вроде
ELF symbols check на неактуальном сизифе?


-- 
ldv

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

Re: [devel] Распараллеливание incoming.

[Igor Vlasenko]

On Sat, Nov 26, 2011 at 03:19:13PM +0400, Dmitry V. Levin wrote:
> > Почему так? Трюк здесь в том, что у этих пакетов зависимости новой версии
> > и старой версии не отличаются.
> 
> Какая разница, чем вызвано изменение сборочной/установочной среды,
> отличиями в зависимостях между старой и новой версией пакета, или
> изменениями в сизифе?  Какой смысл проводить глабальные проверки вроде
> ELF symbols check на неактуальном сизифе?

Для noarch пакетов вроде moodle*-lang-*
ELF symbols check вообще не имеет смысла проводить :)

А noarch пакеты -- это более половины пакетов сизифа.
Я к тому, что в incoming есть большой запас для оптимизации
и распараллеливания.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Распараллеливание incoming.

[Dmitry V. Levin]

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

On Sat, Nov 26, 2011 at 01:26:20PM +0200, Igor Vlasenko wrote:
> On Sat, Nov 26, 2011 at 03:19:13PM +0400, Dmitry V. Levin wrote:
> > > Почему так? Трюк здесь в том, что у этих пакетов зависимости новой версии
> > > и старой версии не отличаются.
> > 
> > Какая разница, чем вызвано изменение сборочной/установочной среды,
> > отличиями в зависимостях между старой и новой версией пакета, или
> > изменениями в сизифе?  Какой смысл проводить глабальные проверки вроде
> > ELF symbols check на неактуальном сизифе?
> 
> Для noarch пакетов вроде moodle*-lang-*
> ELF symbols check вообще не имеет смысла проводить :)

Я же специально сказал: глабальные проверки _вроде_ ELF symbols check.

$ git grep 'noarch package' gb-task-repo-elfsym
gb-task-repo-elfsym:# This check does not apply to noarch packages.
gb-task-repo-elfsym:cut -f3 plan/{add,rm}-bin |fgrep -qs -v noarch || exit 0

Есть ведь и другие глабальные проверки.


-- 
ldv

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

Re: [devel] Распараллеливание incoming.

[Igor Vlasenko]

On Sat, Nov 26, 2011 at 04:25:55PM +0400, Dmitry V. Levin wrote:
> Я же специально сказал: глабальные проверки _вроде_ ELF symbols check.
> $ git grep 'noarch package' gb-task-repo-elfsym
> gb-task-repo-elfsym:# This check does not apply to noarch packages.
> gb-task-repo-elfsym:cut -f3 plan/{add,rm}-bin |fgrep -qs -v noarch || exit 0
> 
> Есть ведь и другие глабальные проверки.

я вот посмотрел,
$ ls -1 gb-task-check-* gb-task-repo-*
gb-task-check-acl
gb-task-check-build
gb-task-check-build-arch
gb-task-check-build-i
gb-task-check-girar
gb-task-check-install
gb-task-check-install-arch
gb-task-check-lastchange
gb-task-check-noarch
gb-task-check-noarch-i
gb-task-repo-elfsym
gb-task-repo-plan
gb-task-repo-sync
gb-task-repo-unmets
gb-task-repo-vercheck

большей части текущий Sisyphus не нужен,

проверкам вида gb-task-repo-vercheck
достаточно текстового листинга вида Sisyphus/files/list/bin.list
или доступа на чтение к копии кеша apt base/pkglist.classic.*

Для проверок на install, elfsym, unmets 
предложения по оптимизации озвучены.
например, для install, если изменения в Сизифе 
не затронули установочные зависимости,
то install check можно делать и на более старой копии сизифа.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Распараллеливание incoming.

[Igor Vlasenko]

On Sat, Nov 26, 2011 at 02:45:55PM +0200, Igor Vlasenko wrote:
> например, для install, если изменения в Сизифе 
> не затронули установочные зависимости,
> то install check можно делать и на более старой копии сизифа.

точнее, можно считать install check на более старой копии сизифа
таким, как будто он выполнен на более новой копии сизифа.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Распараллеливание incoming.

[Dmitry V. Levin]

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

On Sat, Nov 26, 2011 at 02:45:55PM +0200, Igor Vlasenko wrote:
> Для проверок на install, elfsym, unmets 
> предложения по оптимизации озвучены.
> например, для install, если изменения в Сизифе 
> не затронули установочные зависимости,

Вот только для того, чтобы узнать, затронули изменения в Сизифе
установочные зависимости или нет, приходится заново вычислять установочные
зависимости.  То же самое касается elfsym и unmets.

Да, если elfsym в Сизифе не изменился, и пакеты на повторной итерации тоже
не собирались, то повторять ранее успешно пройденный elfsym check незачем.

А вот с unmets так просто уже не разделаться.  Даже если пакеты на
повторной итерации не собирались, зависимости в Сизифе могли измениться
как угодно, и в общем случае проще перепроверить unmets, чем пытаться
угадать, могли ли изменения повлиять на результат.


-- 
ldv

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

Re: [devel] Распараллеливание incoming.

[Igor Vlasenko]

On Sat, Nov 26, 2011 at 05:33:17PM +0400, Dmitry V. Levin wrote:
> > Для проверок на install, elfsym, unmets 
> > предложения по оптимизации озвучены.
> > например, для install, если изменения в Сизифе 
> > не затронули установочные зависимости,
> 
> Вот только для того, чтобы узнать, затронули изменения в Сизифе
> установочные зависимости или нет, приходится заново вычислять установочные
> зависимости.  То же самое касается elfsym и unmets.

Я специально отмечал, что пакеты наподобие moodle-lang-*
обладают важным свойством: поскльку их req/prov по сути не меняются,
то эти пакеты не меняют установочные зависимости других пакетов.

Другими словами, их сборка коммутирует со сборкой всех других пакетов,
и обновление этих пакетов не влияет на elfsym, unmets, install 
проверки на более старом Сизифе.

Это можно вычислить прямо по пакетам, сравнив дампы rpmquery | sort
и проверив, нет ли строгих requires по старой копии base/pkglist.classic.

И эти пакеты достаточно многочисленны. Пол Сизифа - это noarch,
и из них многие должны обладать таким же свойством.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Распараллеливание incoming.

[Dmitry V. Levin]

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

On Sat, Nov 26, 2011 at 04:18:26PM +0200, Igor Vlasenko wrote:
> On Sat, Nov 26, 2011 at 05:33:17PM +0400, Dmitry V. Levin wrote:
> > > Для проверок на install, elfsym, unmets 
> > > предложения по оптимизации озвучены.
> > > например, для install, если изменения в Сизифе 
> > > не затронули установочные зависимости,
> > 
> > Вот только для того, чтобы узнать, затронули изменения в Сизифе
> > установочные зависимости или нет, приходится заново вычислять установочные
> > зависимости.  То же самое касается elfsym и unmets.
> 
> Я специально отмечал, что пакеты наподобие moodle-lang-*
> обладают важным свойством: поскльку их req/prov по сути не меняются,
> то эти пакеты не меняют установочные зависимости других пакетов.

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

> Другими словами, их сборка коммутирует со сборкой всех других пакетов,
> и обновление этих пакетов не влияет на elfsym, unmets, install 
> проверки на более старом Сизифе.

Да, с высокой вероятностью коммутирует, и с высокой вероятностью не
влияет.  Если бы мы хотели реализовать какую-нибудь спекулятивную
оптимизацию, то мы могли бы учесть эту вероятность.  Но если предположить,
что эта вероятность равна 1, то потом в самый неподходящий момент можно
будет получить подземный стук, например, в виде задания, которое не
проходит проверку на анметы, случайно внесенные другим заданием.

> Это можно вычислить прямо по пакетам, сравнив дампы rpmquery | sort
> и проверив, нет ли строгих requires по старой копии base/pkglist.classic.

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


-- 
ldv

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

Re: [devel] Распараллеливание incoming.

[Igor Vlasenko]

On Sat, Nov 26, 2011 at 06:34:05PM +0400, Dmitry V. Levin wrote:
> Да, с высокой вероятностью коммутирует, и с высокой вероятностью не
> влияет.  Если бы мы хотели реализовать какую-нибудь спекулятивную
> оптимизацию, то мы могли бы учесть эту вероятность.  Но если предположить,
> что эта вероятность равна 1, то потом в самый неподходящий момент можно
> будет получить подземный стук, например, в виде задания, которое не
> проходит проверку на анметы, случайно внесенные другим заданием.
> 
> > Это можно вычислить прямо по пакетам, сравнив дампы rpmquery | sort
> > и проверив, нет ли строгих requires по старой копии base/pkglist.classic.
> 
> Если бы у нас не было provides и зависимостей с версиями, то, конечно, все
> можно было бы быстро проверить, но тогда не было бы и тех возможностей, к
> которым мы так привыкли.

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

то, что requires не изменились, это сравнить, нет ли разницы в дампах rpmquery.

также можно быстро сравнить rpmquery -l в пересечении с, например,
свежими файловыми requires (список генерировать при обновлении сизифа)

Provides, к сожалению, меняется всегда, так как меняется version.
предположим, в Provides изменился version.
теперь возьмем откроем base/pkglist.classic и поищем там 
(достаточно быстрая операция) requires на измененные provides.
Если requires на измененные provides нет, либо в этих 
requires не используется сторгое равенство либо <=,
а только > или >=, то, очевидно, новые Provides тоже будут
удовлетворять новые Requires.

Я утверждаю, что в таком случае уже стрго
коммутирует и не влияет, речи о вероятностях
> с высокой вероятностью коммутирует, 
> и с высокой вероятностью не влияет.
уже нет.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] [JT] Распараллеливание incoming.

[Vitaly Lipatov]

 On Sat, 26 Nov 2011 18:34:05 +0400, Dmitry V. Levin wrote:
> On Sat, Nov 26, 2011 at 04:18:26PM +0200, Igor Vlasenko wrote:
 ...
>> Другими словами, их сборка коммутирует со сборкой всех других 
>> пакетов,
 Не понимаю слово «коммутирует» в этом контексте: Розенталь, видимо, 
 медленно поворачивается в гробу,
 потому с моим внутренним словарём управления как-то конфликтует.
 Мне казалось, коммутировать можно что-либо, или же когда третья сторона 
 коммутирует одно с чем-либо другим.

-- 
 С уважением,
 Виталий Липатов,
 Etersoft

Re: [devel] [JT] Распараллеливание incoming.

[Igor Vlasenko]

On Thu, Dec 08, 2011 at 12:12:08AM +0400, Vitaly Lipatov wrote:
> >>Другими словами, их сборка коммутирует со сборкой всех других
> >>пакетов,
> Не понимаю слово ??коммутирует?? в этом контексте: Розенталь,
> видимо, медленно поворачивается в гробу,
> потому с моим внутренним словарём управления как-то конфликтует.
> Мне казалось, коммутировать можно что-либо, или же когда третья
> сторона коммутирует одно с чем-либо другим.

Сорри, за матем.жаргон, новояз от коммутативный
    матем. обладающий свойством коммутативности  независимости результата операции от перестановки её элементов. В более общем смысле действие а * b называется коммутативным, если а*b=b*a.

http://ru.wiktionary.org/wiki/%D0%BA%D0%BE%D0%BC%D0%BC%D1%83%D1%82%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D0%B9

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] [JT] Распараллеливание incoming.

[Мал Скрылёв]

8 декабря 2011 г. 0:19 пользователь Igor Vlasenko
<vlasenko@imath.kiev.ua> написал:
> On Thu, Dec 08, 2011 at 12:12:08AM +0400, Vitaly Lipatov wrote:
> Сорри, за матем.жаргон, новояз от коммутативный
>    матем. обладающий свойством коммутативности  независимости результата операции от перестановки её элементов. В более общем смысле действие а * b называется коммутативным, если а*b=b*a.

Тогда коммутатирует =)

-- 
Малъ Зануда, Скрылёвъ сынъ

[devel] [JT] Распараллеливание incoming.

[Denis G. Samsonenko]

Привет!

8 декабря 2011 г. 11:39 Мал Скрылёв написал:
>> Сорри, за матем.жаргон, новояз от коммутативный
>>    матем. обладающий свойством коммутативности  независимости результата операции от перестановки её элементов. В более общем смысле действие а * b называется коммутативным, если а*b=b*a.
>
> Тогда коммутатирует =)

Помнится, в курсе квантовой механики нам говорили именно о
коммутирующих матрицах и операторах в смысле выше описанных Игорем
свойств.

--
Всего доброго,

Денис.

Re: [devel] [JT] Распараллеливание incoming.

[Dmitriy Kruglikov]

8 декабря 2011 г. 7:15 пользователь Denis G. Samsonenko  написал:

> Помнится, в курсе квантовой механики нам говорили
Радиотехнический факультет, многоканальная электросвязь.
Для меня "коммутатор" == "рубильник (механический или электронный)"...
В контексте "компутеров и ЛВС", "коммутатор" == "коробочка, в которую
кабеля втыкаютъ"...

Вам говорили о "коммутирующих матрицах и операторах",
в силу чего контекст был явно определен и ограничен областью матриц и
операторов.

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


-- 
Best regards,
 Dmitriy Kruglikov.
    QString at, dot, mail, XMPP;
    at = "@";
    dot = ".";
    mail = "Dmitriy.Kruglikov" + $at +"gmail" + $dot + "com";
    XMPP = $mail;

Re: [devel] [JT] Распараллеливание incoming.

[Michael Shigorin]

On Thu, Dec 08, 2011 at 09:25:30AM +0200, Dmitriy Kruglikov wrote:
> Математику я, конечно, люблю и уважаю, но о "коммутативности"
> подумал бы в последнюю очередь, хотя слово это знаю и даже
> помню, что оно означает.

Так один математик другому на пальцах объяснял. :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Распараллеливание incoming.

[Aleksey Avdeev]

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

26.11.2011 15:19, Dmitry V. Levin пишет:
> On Sat, Nov 26, 2011 at 12:58:46PM +0200, Igor Vlasenko wrote:
>> Несколько в сторону, по поводу incoming.
>>
...
>>
>> Для многих пакетов, те же moodle*-lang-* пакеты, к примеру,
>> такое поведение не нужно. 
>> Для таких пакетов заведомо ничего страшного не случится,
>> если они будут собраны на позавчерашнем сизифе, проверены на устанавливаемость
>> на вчерашнем сизифе, включены в сегодняшний сизиф.
>>
>> Почему так? Трюк здесь в том, что у этих пакетов зависимости новой версии
>> и старой версии не отличаются.
> 
> Какая разница, чем вызвано изменение сборочной/установочной среды,
> отличиями в зависимостях между старой и новой версией пакета, или
> изменениями в сизифе?  Какой смысл проводить глабальные проверки вроде
> ELF symbols check на неактуальном сизифе?

  А для всех ли пакетов актуальны проверки, требующие актуальный Сизиф?

  Например, если рассмотреть те же moodle*-lang-* и проверку ELF symbols
check, то:

1. Проверка ELF symbols check для пакетов moodle*-lang-* не нужна
вообще, т. к. эти пакеты не содержат ELF-файлов.

2. Если не нужна проверка ELF symbols check => -1 причина актуализации
Сизифа.

3. Ели подобным образом (по анализу осмысленности применимости) будут
отстрелены все проверки, актуальный Сизиф требующие => для сборки пакета
актуальный Сизиф необязателен.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] Распараллеливание incoming.

[Igor Vlasenko]

И та же логика применима к случаю, когда во время сборки пакета B 
в Сизифе обновились пакеты Ci из сборочного окружения В.

1) Выбрасываем нерелевантные проверки 
(например, если B - noarch, то выбрасываем проверку ELF symbols check)
2) Выбрасываем те Сi, которые не подходят под релевантные проверки
(например - проверка на Unmets, но у Ci -- инвариантные зависимости)

И пересобираем пакет только тогда, когда оба множества 
после выбрасывания не пустые.

On Sat, Nov 26, 2011 at 03:34:02PM +0400, Aleksey Avdeev wrote:
>   Например, если рассмотреть те же moodle*-lang-* и проверку ELF symbols
> check, то:
> 
> 1. Проверка ELF symbols check для пакетов moodle*-lang-* не нужна
> вообще, т. к. эти пакеты не содержат ELF-файлов.
> 
> 2. Если не нужна проверка ELF symbols check => -1 причина актуализации
> Сизифа.
> 
> 3. Ели подобным образом (по анализу осмысленности применимости) будут
> отстрелены все проверки, актуальный Сизиф требующие => для сборки пакета
> актуальный Сизиф необязателен.
> 
> -- 
> 
> С уважением. Алексей.
> 
> 



> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] Распараллеливание incoming.

[Dmitry V. Levin]

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

On Sat, Nov 26, 2011 at 03:34:02PM +0400, Aleksey Avdeev wrote:
> 26.11.2011 15:19, Dmitry V. Levin пишет:
[...]
> > Какая разница, чем вызвано изменение сборочной/установочной среды,
> > отличиями в зависимостях между старой и новой версией пакета, или
> > изменениями в сизифе?  Какой смысл проводить глабальные проверки вроде
> > ELF symbols check на неактуальном сизифе?
> 
>   А для всех ли пакетов актуальны проверки, требующие актуальный Сизиф?

Нет, только для пакетов, которые собирают в Сизиф. :)

>   Например, если рассмотреть те же moodle*-lang-* и проверку ELF symbols
> check, то:
> 
> 1. Проверка ELF symbols check для пакетов moodle*-lang-* не нужна
> вообще, т. к. эти пакеты не содержат ELF-файлов.

Об этом автор проверки позаботился изначально.

> 2. Если не нужна проверка ELF symbols check => -1 причина актуализации
> Сизифа.

Достаточно только одной.

> 3. Ели подобным образом (по анализу осмысленности применимости) будут
> отстрелены все проверки, актуальный Сизиф требующие => для сборки пакета
> актуальный Сизиф необязателен.

Из ложной посылки можно вывести любое следствие.
Есть несколько проверок, результат которых зависит не только от собранных
пакетов, но и от репозитория, на котором они проводятся.  Все эти
проверки, вообще говоря, неупраздняемы.  Например, таковыми являются
gb-task-repo-unmets и gb-task-check-install.  Но их можно оптимизировать,
и повторные выполнения некоторых трудоемких проверок уже оптимизированы.


-- 
ldv

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

Re: [devel] Распараллеливание incoming

[Michael Shigorin]

On Sat, Nov 26, 2011 at 03:19:13PM +0400, Dmitry V. Levin wrote:
> Какая разница, чем вызвано изменение сборочной/установочной
> среды, отличиями в зависимостях между старой и новой версией
> пакета, или изменениями в сизифе?

Если правильно понимаю, это был скорее вопрос про кэш.

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

Кэширование зависимостей может помочь при разрешении мержей,
насколько понимаю: если предположение не сработало -- ладно,
идём по более дорогому пути пересборки; а если сработало,
так можно сэкономить.

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

---
An even worse example was a popular sports web site we worked on.
The site would update sports statistics by holding an exclusive
lock on transactional database tables while waiting for a remote
data service over the internet to respond. The client couldn't
understand why adding more application servers to their
infrastructure made the timeouts worse instead of better.
--- http://lwn.net/Articles/441790/

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/