[devel] I: gyle --test-only by default

[Alexey Tourbin]

On Wed, Mar 20, 2019 at 3:40 PM Dmitry V. Levin <ldv на altlinux.org> wrote:
> On Wed, Mar 20, 2019 at 02:51:39PM +0300, Andrey Savchenko wrote:
> > On Wed, 20 Mar 2019 13:38:57 +0300 (MSK) Ivan Zakharyaschev wrote:
> > > On Wed, 20 Mar 2019, Alexey V. Vissarionov wrote:
> > > > В общем, оптимальный по эргономике вариант видится мне примерно так:
> > > >
> > > > set task=`ssh build.alt build $repo $tag`
> > > > тестируем - лопухнулись, исправляем
> > > > set task=`ssh build.alt build $repo $tag`
> > > > опять тестируем - порядок
> > > > ssh build.alt commit $task
> > >
> > > Сейчас это ssh build.alt task run --commit $task
> > >
> > > Если состояние репозитория и задания позволяют, оно сразу же делает commit
> > > сейчас, без пересборки.
> > >
> > > Просто тут дело не только в интерфейсе, но и в алгоритме работы (и его
> > > спецификации) сборочницы: задание может быть закоммичено, только если оно
> > > было собрано исходя из текущего состояния репозитория,
> >
> > Но ведь это избыточное условие для обеспечения пересобираемости
> > пакетов и транзакционности сборки. Если пакет A не входит
> > в сборочное окружение пакета B (в т.ч. и по сборочным зависимостям
> > пакетов и сборочного окружения B, которые могут быть в свою
> > очередь рекурсивными), то пакет B можно пересобирать вне
> > зависимости от изменений пакета A.
>
> У нас очень дорогая проверка того, входит ли пакет A в сборочное окружение
> пакета B.

Она не очень дорогая. При генерации /var/cache/apt/pkgcache.bin 2
секунды уходит на распаковку pkglist.classic.xz, но это не подавляюще
много. По-моему, проверку нельзя легко и сильно удешевить.

> > По сути, это классическая задача поиска путей в графе и @viy уже
> > много раз писал на эту тему и то, как её алгоритмизировать.
>
> Для того, чтобы эту задачу решать быстро, насколько я понимаю,
> надо упростить зависимости и отказаться от apt в пользу инструментов,
> заточенных на решение этой задачи.

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

Ну и потом специальный инструмент всё равно не сможет работать чисто
на pkglist'ах, есть же еще RPMS.hasher, который надо сканировать, и
генерировать общее состояние, где RPMS.hasher перекрывает основной
репозиторий; и значит всё равно появляется выбор. Получается
подозрительно похоже на apt.