On Mon, Mar 01, 2004 at 11:32:45AM +0300, Andrey Orlov wrote:

 >> 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)
 >> Красиво? Логика мне подсказывает, что лишь последняя запись здесь имеет
 >> смысл.
 AO> То, что вы сказали, верно при предположении, что:
 AO>    libc.so.6(GLIBC_2.2) provide libc.so.6(GLIBC_2.1.3) 
 AO> Что, конечно, в данном конкретном случае может быть и так, но вот в общем случае ...
 AO> Я живо представил себе "дуп" вида :
 AO> python == 2.2
 AO> python == 2.3

Речь в даном случае идёт исключительно о shared objects. В более общем
виде это работать не будет. Однако даже только для libc.so.6(GLIBC_*)
выигрыш будет ощутим.

 AO> И что-то у меня не возникает уверенности в работоспособности этого пакета вообще,
 AO> а уж тем более - при соблюдении только последней кляузы.

Разумеется.

 AO> Иными словами, упростить такие зависимости, конечно, можно, но нужна машина
 AO> вывода более хорошая, чем sort|unique|tail -1 ;)

Обрабатывать только условия вида
lib(.*).so.([\d+])\((.*)\)

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

Здесь я бы предпочёл создавать список ручками. У меня есть подозрение, что
будет работать и на автомате, но пусть лучше сначала поработает в ручном
режиме.

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

Эта парочка действительно только при попытке более широко трактовать мои
предожения :)

 >> Зато есть два основных позитивных, это уменьшение размера apt и rpm баз,
 >> увеличения скорости работы apt, увеличение скорости работы hasher'а.
 AO> Сдается мне, что основной тормоз apt & rpm баз не в количестве зависимстей,
 AO> а в их кривой обработке, так что и копать надо в другую сторону. Вот то, что
 AO> снижение количества зависимостей приводит к их большей осозноваемости
 AO> представляет некий плюс.

Да, ну и на нынешних машинах это можно считать единственым плюсом.

 >> Вопрос -- оно нам надо? В смысле -- я могу это сделать, но это имеет смысл
 >> только при включении результата в Сизиф (и пользу от него мы получим только
 >> после ближайшей полной пересборки Сизифа).
 AO> Мне кажется, что в общем случае без создания серьезной машины вывода работающей
 AO> над зависимостями и исключающей те из них, которые выводимы через другие при помощи
 AO> некоторых правил вывод, это будет глюкодром. С другой стороны, от попытки проведения 
 AO> работы такого рода может произойти масса полезных сторонних эффектов, как для вас 
 AO> лично, так и для Сизиф, так что я бы с интересом за этим понаблюдал.
 AO> ЗЫ: Пример стороннего эффекта - средства диагностики корректости зависимостей для ручного
 AO> исправления. Я тут склепал прототип python.req python.prov, а применив его к собственно python ;),
 AO> обнаружил, что некоторые файлы в пакете нахрен не нужны. 

Пока мои предложения больше косметически, и должны лишь увеличить SNR.

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

http://dimline.ru/