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

[Dmitry V. Levin]

On Thu, Mar 21, 2019 at 06:58:09AM +0300, Alexey Tourbin wrote:
> On Wed, Mar 20, 2019 at 3:40 PM Dmitry V. Levin wrote:
[...]
> > У нас очень дорогая проверка того, входит ли пакет A в сборочное окружение
> > пакета B.
> 
> Она не очень дорогая. При генерации /var/cache/apt/pkgcache.bin 2
> секунды уходит на распаковку pkglist.classic.xz, но это не подавляюще
> много. По-моему, проверку нельзя легко и сильно удешевить.

Для того, чтобы выяснить, входит ли пакет A в сборочное окружение пакета B,
нам в общем случае нужно вычислить это сборочное окружение пакета B.
Сейчас для этого надо
- создать базовый чрут;
- распаковать спек-файл пакета B, извлечь из него BuildRequires(pre),
  установить по ним пакеты;
- распаковать исходный код, вычислить BuildRequires, вычислить по ним
  пакеты.

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

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

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

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

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

В таком варианте да.  А если обновлять pkglist'ы после каждого сабтаска
и не сканировать RPMS.hasher?  Если не генерить pkglist'ы с нуля, а патчить,
это не должно быть долго.


-- 
ldv
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 801 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20190324/77ecd523/attachment.bin>