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

["Денис Смирнов" <mithraen@altlinux.ru>]

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

On Mon, Mar 01, 2004 at 07:25:20AM +0300, Алексей Турбин wrote:

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

По крайней мере зависимость на функцию шелл-скрипта должна быть
достаточным поводом, чтобы убрать зависимость на /bin/sh.

А насчёт дупов... В аттаче пример списка requires из одного пакета.

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

man что? (редактор -- vim).

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

Мда. Без более глубокого копания в apt сделать красиво не получится
(хорошо бы научить apt обрабатывать "виртуальные" зависимости, которые
физически не прописаны, но подразумеваются). А пока действительно в этом
смысле ваш вариант оказывается лучше.

>> 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)
>> Красиво? Логика мне подсказывает, что лишь последняя запись здесь имеет смысл.
 AT> Тогда первая и последняя.  Но произвольный формат symbol versioning
 AT> может не совпадать с rpmvercmp, а не хотелось бы внедрять неточные
 AT> алгоритмы.

Для начала можно обработать конкретный частный случай.

 >> 5. libXXX и libXXX.so.Y
 >> Логика мне подсказывает, что вторая зависимость такого вида чаще всего
 >> является лишь уточнением первой.
 AT> Логика также подсказывает, что первая зависимость появилась вручную, а
 AT> вторая -- автоматически.  Из чего вывод: не надо проставлять зависимости
 AT> вручную, кроме особых случаев.

Претензии не ко мне :)

>> 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
 AT> У меня были мысли не эту тему, см.
 AT> Sun, 16 Nov 2003 [devel] packagereq/buildreq proposal
 AT> 20031116145830.GC1863@julia.office.altlinux.ru

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

Разумеется. С другой стороны можно идти последовательным улучшением
(добавляя хаки, логика которых прозрачна и работоспособность
гарантирована).

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

http://dimline.ru/

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