Re: [devel] [devel-ports] renoarch: noarch.rpm -> src.rpm

[Anton Farygin <rider@basealt.ru>]

On 15.11.2021 16:21, Ivan A. Melnikov wrote:
> On Mon, Nov 15, 2021 at 03:15:18PM +0300, Anton Farygin wrote:
>> On 15.11.2021 14:14, Ivan A. Melnikov wrote:
>>> К тому же, как тут пишет рядом rider@, эту задачу сложно
>>> формализовать. Зависимости могут быть неточными (когда
>>> написано BR: foo, а на самом деле требуется foo > 2.0),
>>> специфичными для платформы и так далее. Циклы надо как-то
>>> разрывать опять же.
>> На самом деле нужно написать solver, который будет разделять бинарные
>> жёсткие зависимости и сборочные зависимости.
>>
>> unmet'ы при сборке вылезают из-за бинарых (библиотечных) зависимостей и
>> именно по ним исходные пакеты надо упорядочивать.
>>
>> Мы сделали попытку написать такой solver (oneandhalf опция в rdb), но циклы
>> оно всё равно рвать не умеет.
>>
>> По идее можно попробовать добавить параметр к запросу, который позволит
>> порвать циклы вручную. Или опцию, которая будет искать и рвать все
>> циклические зависимости и сортировать без их учёта).
>>
>> Последнее мне нравится больше всего, т.к. всё равно приходится с этими
>> пакетами что-то делать для сборки.
> У меня тоже сделана подобная штука. Сначала определяется множество
> пакетов исходного репозитория (скажем, Sisyphus x86_64), такое, что
> их совместная сборка в целевой репозиторий
> (скажем, sisyphus_riscv64) не порождает новых
> анметов ни по сборочным, ни по бинарным зависимостям, ну и естественно
> содержащее нужные пакеты. Потом происходит попытка упорядочить эти
> для задачи пакеты по принципу "пакет А собирается
> раншье пакета Б, если результаты сборки пакета А попадают в сборочный
> chroot пакета Б". Сборочный chroot обсчитывается нагло замыканием
> сборочных зависимостей через обход в ширину графа зависимостей
> в исходном репозитории, совсем не так, как
> это делает apt, но для моих целей примерного сходства достаточно.
>
> Циклы при упорядочивании рвутся где придётся, но записываются
> и показываются отдельно от списка пакетов, чтобы можно было
> оценить ужас происходящего и что-то с этим сделать.
>
> Есть опции вида "игнорировать зависимость foo от bar" (чтобы
> порвать какой-то цикл в конкретном месте) и "игнорировать
> все зависимости на foo". Последняя более полезна и спользуется
> почти всё время.
>
> Чаще всего это даже работает.

А давай сравним вывод ?
curl 
'https://rdb.altlinux.org/api/package/what_depends_src?packages=ocaml&branch=sisyphus&depth=1&dptype=both&finite_package=false&onea
ndhalf=true'|jq  -r '.dependencies[].name'


Как у тебя получилось отсортировать все пакеты, которые зависят по 
сборки и runtime от ocaml (включая те, что из него собираются) ?