То есть хочется запрос, который для определенного репозитория выводит все зависимости (Requires/Provides/Conflicts/Obsoletes), которые не сопоставляются для заданного репозитория?

Например, A замещает (Obsoletes) B, но B при этом на текущий момент в репозитории никем не предоставляется (Provides) => такая B - зависимость для зачистки. Я правильно понимаю?

Насчёт Provides: я так понимаю, необходимо определить те зависимости (Provides), которые когда-то были кому-то нужны, но эти "кто-то" уже отсутствуют в заданном репозитории? А что если такие провайды используются где-нибудь при сборке образов (в таком случае можно случайно (или не совсем) сломать сборку образа)?

Прошу прощения, был в отпуске, сейчас вспомнил.

(Ответ для Anton Zhukharev на комментарий #1)
> То есть хочется запрос, который для определенного репозитория выводит
> все зависимости (Requires/Provides/Conflicts/Obsoletes), которые не
> сопоставляются для заданного репозитория?
Лучше бы не для данного, а со временнОй отсечкой (скажем, для сизифа это может быть пять лет или два бранча -- если что-то с конфликтом на него было в p8 и пропало в p9, к p11 можно считать такое нерелевантным, т.к. обновление с p8 должно проходить через _два_ бранча, где такого уже нет).

> Например, A замещает (Obsoletes) B, но B при этом на текущий момент
> в репозитории никем не предоставляется (Provides) => такая B - зависимость
> для зачистки. Я правильно понимаю?
По сути да -- с учётом того, что пакет B также предоставляет самого себя (B).

> Насчёт Provides: я так понимаю, необходимо определить те зависимости
> (Provides), которые когда-то были кому-то нужны, но эти "кто-то" уже
> отсутствуют в заданном репозитории? А что если такие провайды используются
> где-нибудь при сборке образов (в таком случае можно случайно (или не совсем)
> сломать сборку образа)?
По части Provides: всё в принципе сложней, поскольку они бывают и для внешних потребителей (например, совместимости с чем-нить для редхата или сузи), и для применения в дистрибутивных профилях.

Я бы тут начинал именно с Conflicts: и Obsoletes:, а к более нетехнически сложным Provides: переходил уже после решения задачи попроще (которая с учётом желательности именно временной отсечки сама по себе не особо тривиальна).  Полуавтоматизировать тут разве что кластеризацией результатов получится, поскольку нужные ручные обычно точечные, но не массовые (хотя и такое исключить нельзя).

Можно забрать условный http://ftp.altlinux.org/pub/distributions/archive/sisyphus/task/archive/_207/212240/daily/ той самой пятилетней давности и часть достоверных сведений вида "было, но пропало" получить из него (это не закроет ещё более древних "потеряшек", которых не было уже и тогда, но конфликты на которые стоят до сих пор -- например, design-graphics-education).

В принципе можно и все (или ежемесячные) daily/{x86_64,noarch}/base/pkglist.classic.xz позабирать да поразбирать, но мне кажется, что для такой задачки не в математическом, а в инженерном варианте решения это слишком.

И на самом деле может иметь смысл не городить итеративный огород, а предпринять единоразовый набег на конкретно взятый сизиф (в идеале до p11) и в дальнейшем подвязав к удалению пакета проверку на наличие Obsoletes:/Conflicts: на порождаемые из него бинарные подпакеты с уведомлением майнтейнеров тех пакетов, где эти O:/C: станут мусором (лишь бы эти уведомления не оказались спамом в плане частоты/многочисленности).

Не могу сказать, что мне полностью понятна цель и смысл расчистки "висячих/мёртвых" зависимостей пакетов в репозитории.

В БД мы храним метаинформацию извлекаемую из пакетов репозиториев, т.е. всё что есть в хэдереах .rpm.
У нас уже реализованы механизмы поиска и разрешения зависимостей пакетов для аналитических запросов и отображения этой информации на packages.altlinux.org.
При реализации этого функционала используется непосредственно часть функций из librpm (в части сравнения версий при разрешении зависимостей) и в определённых местах мы вынуждены были повторить поведение apt для получения результатов аналогичных таковым в работе с пакетами на реальной системе.

Тут главный момент, что apt при разрешении зависимостей помимо метаинформации из хэдеров rpm-пакетов использует ещё и свои индексные файлы, в частности для разрешения файловых зависимостей.

По моему скромному мнению, решать озвученную задачу (если я правильно понял, что собственно планируется сделать) нужно именно с использованием непосредственно функционала apt и rpm на каком то конкретном консистентном состоянии репозитория.

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

Относительно удаления Provides, которые никто не хочет - а что будет, когда в репозиторий попадут новые пакеты или новые версии пакетов, которые зависят от "расчищенных" ранее зависимостей?

Ну и к цифрам: какое количество зависимостей из условны 250-300 тысяч таким образом удастся убрать? Есть какие то оценки результата, хотя бы примерные?

Created attachment 14340 [details]
pkglist-query.cc им. glebfm@

Спасибо за вопросы!  Постараюсь кратенько зафиксировать частичную выжимку сегодняшнего общения с практикантами по теме.

Из замеченных интересных особых случаев -- zoneminder: >3000 перловых Provides:, причём похоже на то, что нужны они только ему самому (похоже, надо AutoProv: no или как минимум noperl добавить).

(Ответ для Danil Shein на комментарий #3)
> Не могу сказать, что мне полностью понятна цель и смысл расчистки
> "висячих/мёртвых" зависимостей пакетов в репозитории.
Ускорение работы apt в первую очередь (в т.ч. для hasher => сборочницы, множитель -- _минимум_ сотни тысяч запусков; тут и секунда уже выгода).

> В БД мы храним метаинформацию извлекаемую из пакетов репозиториев,
> т.е. всё что есть в хэдереах .rpm.
Про pkglist.classic и pkglist-query в курсе, кстати? (прилагаю)
Или забираете инкрементально из заданий?
Это сводка заголовков пакетов из конкретного состояния репозитория.

> При реализации этого функционала используется непосредственно часть функций
> из librpm (в части сравнения версий при разрешении зависимостей) и в
> определённых местах мы вынуждены были повторить поведение apt для получения
> результатов аналогичных таковым в работе с пакетами на реальной системе.
Метаданные каждый раз поднимаете из файликов?  Посмотрите apt-pipe, когда-то Большаков писал, помнится -- его можно инициализировать при переходе на конкретное задание, дальше гонять команды по уже горячему состоянию.

> По моему скромному мнению, решать озвученную задачу (если я правильно понял,
> что собственно планируется сделать) нужно именно с использованием
> непосредственно функционала apt и rpm на каком то конкретном консистентном
> состоянии репозитория.
В целом да; об этом тоже сегодня поговорили с ребятами.

> По поводу удаления Conflicts и Obsoletes - не случится ли так, что после
> "расчистки" это доставит массу радости пользователям, которые давно не
> обновлялись либо по какой-то причине сохраняют установленными в системе
> пакеты, которые уже удалены из текущего состояния репозитория?
Вот потому и уточнил в comment 2 насчёт отсечки в пару бранчей; цитирую выработанную сегодня формулировку:

---
по тому, что точно было, но уже отсутствует:
возьмите http://ftp.altlinux.org/pub/distributions/ALTLinux/{4.0,4.1,p{5,6,7,8}}/branch/{noarch,x86_64}/base/pkglist.classic.xz и дёрните из них %name (возможно, и [%{providename}], но это уже по вкусу) — вычтя из этого сизифные [%{name}] и соотв. провайдесы, получите список того, что ГАРАНТИРОВАННО было И исчезло.

соответственно то, что C: или O: имя из такого списка — ГАРАНТИРОВАННО* "наш клиент"
---

То, чего _никогда_ не было -- скорее всего, или ошибка в спеке, или Provides: для внешнего пакета, которого в сизифе никогда не было и обычно никогда не будет (для _строгого_ ответа на этот вопрос надо разобрать метаданные всех заданий плюс все известные состояния репозиториев до транзакционной сборочницы, но математическая точность нам и не требуется покрмере на данном этапе).

Что до пользователей, которые давно не обновлялись (скажем, до сих пор на p7): так им сперва понадобится обновиться до промежуточных стабильных репозиториев, где эти C:/O: в наличии => вынос устаревших пакетов произойдёт на этой стадии, потому и предложен зазор в _два_ бранча (он останется неплохим даже после свежеответвлённого p11).

> Относительно удаления Provides, которые никто не хочет - а что будет, когда
> в репозиторий попадут новые пакеты или новые версии пакетов, которые зависят
> от "расчищенных" ранее зависимостей?
И как они попадут, если при этом будет попытка сгенерировать unmet?

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

> Ну и к цифрам: какое количество зависимостей из условны 250-300 тысяч таким
> образом удастся убрать? Есть какие то оценки результата, хотя бы примерные?
Порядка 1% даёт один zoneminder... помножьте на кол-во собираемых заданий (и ещё учтите, что в каждом из них сейчас минимум три запуска apt для хотя бы одного собираемого, а не удаляемого, пакета: hsh --query-repackage, собственно hsh и installcheck; может, и больше, но эти сходу вспомнил).

Думаю, несколько тысяч.  В плохом случае -- несколько десятков тысяч (это если майнтейнеры расслабились и генерят ненужные provides оптом, есть одна подозрительная на сей счёт подсистема).

С zoneminder и его provides всё в порядке.
Возможно это надо вынести в отдельные перловые подпакеты, но это не вопрос этой задачи.

и ответ Шигорину Мише на вопрос как кто и что грузит - там есть информация, про pkglist мы естественно в курсе:

https://git.altlinux.org/people/dshein/public/?p=altrepodb.git

В целом задача выглядит странно я бы точно ей не советовал заниматься на этапе JOIN. 

Думаю что мы не будем делать такой функционал, т.к. всё это на усмотрение ментейнера и зависит от массы факторов, в том числе времени жизни такой "лишней" зависимости.