[devel] Мусор в Requires

[devel] Мусор в Requires

[Денис Смирнов]

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

Поглядел я тут в 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


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

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

[Денис Смирнов]

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

On Mon, Mar 01, 2004 at 01:13:33AM +0300, Денис Смирнов wrote:

В предыдущем письме subject был неправильный.

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

http://freesource.info


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

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

[Денис Смирнов]

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

On Mon, Mar 01, 2004 at 01:20:40AM +0300, Денис Смирнов wrote:

 ДС> В предыдущем письме subject был неправильный.

Тьфу, что за напасть? quis == requires.

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

http://freesource.info


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

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

[Alexey Tourbin]

[-- 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 --]

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

[Andrey Orlov]

On Monday 01 March 2004 01:13, Денис Смирнов 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)
>
> Красиво? Логика мне подсказывает, что лишь последняя запись здесь имеет
> смысл.

То, что вы сказали, верно при предположении, что:

   libc.so.6(GLIBC_2.2) provide libc.so.6(GLIBC_2.1.3) 

Что, конечно, в данном конкретном случае может быть и так, но вот в общем случае ...
Я живо представил себе "дуп" вида :

python == 2.2
python == 2.3

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

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

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

Из вашей логики следует, что ваше предложение будет "чаще всего" работать.

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

Выше парочка нашлась

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

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

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

Мне кажется, что в общем случае без создания серьезной машины вывода работающей
над зависимостями и исключающей те из них, которые выводимы через другие при помощи
некоторых правил вывод, это будет глюкодром. С другой стороны, от попытки проведения 
работы такого рода может произойти масса полезных сторонних эффектов, как для вас 
лично, так и для Сизиф, так что я бы с интересом за этим понаблюдал.

ЗЫ: Пример стороннего эффекта - средства диагностики корректости зависимостей для ручного
исправления. Я тут склепал прототип python.req python.prov, а применив его к собственно python ;),
обнаружил, что некоторые файлы в пакете нахрен не нужны. 

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

[Денис Смирнов]

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

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/

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

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

[Денис Смирнов]

[-- 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 --]

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

[Michael Shigorin]

On Mon, Mar 01, 2004 at 11:32:45AM +0300, Andrey Orlov wrote:
> ЗЫ: Пример стороннего эффекта - средства диагностики
> корректости зависимостей для ручного исправления. Я тут склепал
> прототип python.req python.prov, а применив его к собственно
> python ;), обнаружил, что некоторые файлы в пакете нахрен не
> нужны. 

Помнится, Бормотов упоминал о своих трудах на эту тему для rpm в
ASP (или еще для BCL?).  Не видел?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

[Andrey Orlov]

On Monday 01 March 2004 19:53, Денис Смирнов wrote:
> Речь в даном случае идёт исключительно о shared objects. В более общем
> виде это работать не будет. Однако даже только для libc.so.6(GLIBC_*)
> выигрыш будет ощутим.

Ну-ка /usr/lib/libpython2.3.so vs  /usr/lib/libpython2.4.so  ?
Или libqt.so vs libqt2.so ? 
Так или иначе вы берете некое потолочное допушение об обратной 
совместимости библиотек, что вообще гря неверно.


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

Нет, она действительна при попытке найти постулаты для ваших следствий ;), так
как мы очень быстро упираемся в допущение, которое ниоткуда не следует.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

[Денис Смирнов]

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

On Tue, Mar 02, 2004 at 12:59:29AM +0300, Andrey Orlov wrote:

 AO> Ну-ка /usr/lib/libpython2.3.so vs  /usr/lib/libpython2.4.so  ?
 AO> Или libqt.so vs libqt2.so ? 
 AO> Так или иначе вы берете некое потолочное допушение об обратной 
 AO> совместимости библиотек, что вообще гря неверно.

Я не предлагаю смотреть на версию. Я предлагаю из списка
/usr/libpython2.4.so(ABC_1.2.3)
/usr/libpython2.4.so(ABC_2.3.4)

убить первый за ненадобностью.

>  AO>> Выше парочка нашлась
>> Эта парочка действительно только при попытке более широко трактовать мои
>> предожения :)
 AO> Нет, она действительна при попытке найти постулаты для ваших следствий ;), так
 AO> как мы очень быстро упираемся в допущение, которое ниоткуда не следует.

В этот раз ваш пример связан с тем, что я ничётко выразил свою идею :)

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

http://dimline.ru/


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

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

[Dmitry V. Levin]

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

On Mon, Mar 01, 2004 at 07:53:48PM +0300, Денис Смирнов wrote:
> 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_*)
> выигрыш будет ощутим.

Этого нельзя делать в случае с разделяемыми библиотеками, и тем более в
случае с glibc.

См. тж. http://people.redhat.com/drepper/dsohowto.pdf


-- 
ldv

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