[devel] Re: Мусор в Requires

[Alexey Tourbin <at@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 2889 bytes --]

On Mon, Mar 01, 2004 at 01:13:33AM +0300, Денис Смирнов wrote:
> 1. Убиение дупов. Периодически в разных пакетах я вижу полосы из нескольких
> /bin/sh, иногда и другие пакеты также дупятся. Это хоть и некритично, но

AFAIK, дупы уже убиваются, в пределах каждой стадии зависимостей.

* Thu Jan 29 2004 Dmitry V. Levin <ldv@altlinux> 4.0.4-alt32
...
- build/reqprov.c(addReqProv):
  + enhanced duplicates elimination algorithm,
    it now covers all known optimization cases;
  + implemented %_deps_optimization support.
...

Насчет /bin/sh вообще согласен: самые частые зависимости обычно самые
бесполезные (я даже убиваю некоторые бесполезные зависимости в
/usr/lib/rpm/perl.req).  Система, в которой нет /bin/sh, просто
непригодна для какого-либо обновления.  Зависимость на /bin/sh нужна
в архи-частных случаях. :)

> 2. Если требется, например libc.so.6 и libc.so.6(GLIBC_2.0), то первая запись

Прикрутите ispell к редактору.

> явно не имеет смысла ни для apt, ни для rpm (любой пакет которой provides
> второй вариант обязательно будет provides первый вариант, насколько я понимаю).
> 
> Решение: для каждой зависимости вида lib([a-z]+).so.(\d+)\(.*\) удалять
> зависимость вида lib$1.so.$2

Тогда будет невозможен анализ зависимостей типа
apt-get showpkg 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)
> Красиво? Логика мне подсказывает, что лишь последняя запись здесь имеет смысл.

Тогда первая и последняя.  Но произвольный формат symbol versioning
может не совпадать с rpmvercmp, а не хотелось бы внедрять неточные
алгоритмы.

> 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

У меня были мысли не эту тему, см.
Sun, 16 Nov 2003 [devel] packagereq/buildreq proposal
20031116145830.GC1863@julia.office.altlinux.ru

> Вопрос -- оно нам надо? В смысле -- я могу это сделать, но это имеет смысл

Думаю, что надо, но не всё сразу. :)
В целом, нужно стремиться к точным алгоритмам, а это сложнее, чем хаки.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]