On Thu, Mar 21, 2019 at 02:50:47AM +0300, Andrey Savchenko wrote:
> On Wed, 20 Mar 2019 18:39:37 +0300 Dmitry V. Levin wrote:
> > On Wed, Mar 20, 2019 at 04:09:44PM +0300, Andrey Savchenko wrote:
> > > On Wed, 20 Mar 2019 16:04:22 +0300 Dmitry V. Levin wrote:
> > > > On Wed, Mar 20, 2019 at 03:56:23PM +0300, Andrey Savchenko wrote:
> > > > > On Wed, 20 Mar 2019 15:51:00 +0300 Dmitry V. Levin wrote:
> > > > > > On Wed, Mar 20, 2019 at 03:47:13PM +0300, Andrey Savchenko wrote:
> > > > > > [...]
> > > > > > > Наша система зависимостей на порядок проще, поэтому при надлежащей
> > > > > > > реализации проблем с временем быть не должно.
> > > > > > 
> > > > > > У меня есть основания полагать, что это, к сожалению, не так.
> > > > >  
> > > > > Прошу озвучить эти основания. У нас есть только BuildRequires
> > > > > и Requires. С точки зрения обсуждаемой задачи BuildPreReq можно
> > > > > приравнять к BuildRequires.
> > > > 
> > > > У нас есть Provides, Requires, Conflicts, BuildRequires.
> > > > 
> > > > (ещё существует BuildConflicts, но для вычисления сборочной среды
> > > > BuildConflicts не участвует и про него можно забыть).
> > > > 
> > > > Все эти 4 вида зависимостей бывают версионированными с диапазоном версий.
> > > > У виртуальных пакетов (тех сущностей, которые фигурируют в Provides)
> > > > бывают альтернативные провайдеры, и выбор провайдера из множества
> > > > не является произвольным.
> > > 
> > > Все эти виды зависимостей есть и в portage, все они могут быть
> > > версионированными, вирутальными, с диапазонами значений, вида A или
> > > B или C. Но кроме этого есть зависимости по флагам, со своими
> > > пересечениями, объединениями и условными зависимостями. И всё это
> > > работает за разумное время.
> > 
> > Ну я же сильно упростил.
> 
> Я тоже сильно упростил, умолчав про слоты, профили, попакетную
> настройку USE-флагов, сильные и слабые зависимости, сборочные хост
> зависимости для кросс-компилирования, логические ограничения на
> комбинации флагов и многое другое.
> 
> И со всей этой неимоверной сложностью обсуждаемая задача решена
> и работает за разумное время (да, бывают баги, да, не всегда
> идеально, но работает), поэтому у меня волосы встают дыбом, когда
> мне говорят, что в Альте, на существенно более простой системе
> зависимостей, это якобы невозможно.

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

> > BuildRequires являются некоей функцией исходного
> > кода и сборочной среды, они вычисляются путём выполнения произвольного
> > кода внутри hasher chroot.
> 
> Замечательно. Но ведь наша сборочница гарантирует
> воспроизводимость; значит, это не произвольный код, а вполне
> детерминированное состояние по входным параметрам; значит, это всё
> выстраивается в виде графа зависимостей между атомарными элементами
> и задача вполне разрешима.

К сожалению, именно произвольный код, выполняющийся внутри hasher chroot.
Это часть наследия, которое нам досталось вместе с rpm.
Максимум, что мы можем себе позволить, не отказываясь от этого наследия,
это постулировать, что сборочная среда определяется только репозиторием и
сборочницей, и на этом основании использовать кэшированный результат,
если исходный код и репозиторий не поменялись.
> 
> > Т.е. у нас зависимости гораздо более гибкие, но за эту гибкость приходится
> > платить.
> > 
> > > Поэтому вполне возможна реализация решения подобной задачи за
> > > разумное время и в Альте.
> > 
> > Для того, чтобы эта задача имела решение за разумное время, нам нужно
> > отказаться от избыточной гибкости и перейти на декларативные сборочные
> > зависимости.
> 
> Не вижу такой необходимости. Любой гибкой зависимости в конечном
> счёте отвечает конкретный пакет, поэтому можно выстроить
> отображение гибких зависимостей на конкретные пакеты, их
> предоставляющие, поэтому задача сводится к задаче поиска на
> попакетных зависимостях с операторами AND, OR, NOT.

Из-за этой гибкости сведение к логической задаче имеет гораздо большую
вычислительную сложность, чем решение этой логической задачи.

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

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

Шелл - это прокладка между вызываемыми программами.


-- 
ldv