Поглядел я тут в requires пакетов, и подумалсь мне -- их же можно в 2-3 раза
короче сделать!

У меня родилось несколько предложений по очистке requires.

1. Убиение дупов. Периодически в разных пакетах я вижу полосы из нескольких
/bin/sh, иногда и другие пакеты также дупятся. Это хоть и некритично, но
"неаккуратненько" (c) известный анекдот

Предложение -- в findreq перед тем, как отдавать список найденых requires
его отсортировать и почистить (sort|uniq)

2. Если требется, например libc.so.6 и libc.so.6(GLIBC_2.0), то первая запись
явно не имеет смысла ни для apt, ни для rpm (любой пакет которой provides
второй вариант обязательно будет provides первый вариант, насколько я понимаю).

Решение: для каждой зависимости вида lib([a-z]+).so.(\d+)\(.*\) удалять
зависимость вида lib$1.so.$2

3. Привожу пример:
    - libc.so.6
    - libc.so.6(GLIBC_2.0)
    - libc.so.6(GLIBC_2.1)
    - libc.so.6(GLIBC_2.1.2)
    - libc.so.6(GLIBC_2.1.3)
    - libc.so.6(GLIBC_2.2)
    
Красиво? Логика мне подсказывает, что лишь последняя запись здесь имеет смысл.

Точно такая же извращённая ситуация со многими другими библиотеками (сходу
вспоминаю libdl, libm, libacl).

4. Разборки с glibc-core.

Существуют такие полезные библиотеки как libm.so и libdl.so. Зависимости на
них встречаются часто, однако находятся они в glibc-core. Так как у меня есть
большие сомнения, что когда-либо эти библиотеки (вернее их glibc-версии)
будут отделены от glibc-core, то я предлагаю сделать так:

Если есть, зависимость на libc.so.6(GLIBC_2.2), то зависимости на:
libm.so.6
libdl.so.6
libm.so.6(GLIBC_2.1) (или любую другую версию _не больше_ чем требует libc)
libdl.so.6(GLIBC_2.1) (или любую другую версию _не больше_ чем требует libc)

5. libXXX и libXXX.so.Y

Логика мне подсказывает, что вторая зависимость такого вида чаще всего
является лишь уточнением первой.

Предложение: в подобных ситуациях удалять первую зависимость.

6. Есть пары пакетов, один из которых всегда требует другого. Обычно это
какая-то программа, и основная библиотека, на которой она построена. Кроме
того есть пакеты, всегда представляющие пару provides (например sh, который
предоставляет sh и /bin/sh).

Примеры:
 - tcl и libtcl
 - tk и libtk
 - acl и libacl
 - sh и /bin/sh

Предложение: добавить механизм замен пар (или групп) пакетов на один, например:

tcl + libtcl -> tcl
tk + libtk   -> tk
acl + libacl -> acl
sh + /bin/sh -> sh

Реализация каждой их этих оптимизаций достаточно простая (всё вместе займёт
пару часов, не считая тестирования), и я пока не вижу ни одного негативного
побочного эффекта от этой фичи.

Зато есть два основных позитивных, это уменьшение размера apt и rpm баз,
увеличения скорости работы apt, увеличение скорости работы hasher'а.

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

-- 
С уважением, Денис

http://freesource.info