[devel] Requires optimization/pruning

[Alexey Tourbin]

On Wed, Mar 09, 2011 at 01:20:41PM +0200, Michael Shigorin wrote:
> On Sat, Feb 05, 2011 at 08:41:03AM +0300, Alexey Tourbin wrote:
> > Насчет оптимизации зависимостей между подпакетами.  Мне совсем недавно
> > пришло в голову, что зависимости можно оптимизировать ещё сильнее:
> > а именно, оптимизировать можно не только зависимости, удовлетворённые
> > через Provides, но и зависимости, удовлетворенные через Requires! Ж-)
> > 
> > Пусть например пакет rpm требует две зависимости
> > librpm = 4.0.4-alt16
> > libc.so.6()(64bit)
> > а пакет librpm в свою очередь требует среди прочих зависимость
> > libc.so.6()(64bit)
> > 
> > Тогда из пакета rpm можно удалить зависимость на libc.so.6()(64bit).
> > То есть некоторые зависимости подпакетов иногда "отоваривать", как говорит
> > лидер нации, через базовый подпакет.  Что в принципе имеет смысл.
> > 
> > Но там сложнее сделать, поскольку две Requires зависимости нельзя
> > сравнивать напрямую.  И это не будет хорошо работать с set-версиями,
> > потому что обычно будут разные/несравнимые подможества.  А оптимизация
> > зависимостей делается прежде всего, чтобы снизить нагрузку на
> > pkglist/pkgcache и apt, которая подскочила из-за set-версий.
> 
> Может, всё-таки обрезать в pkglist, а не в самих пакетах?
> 
> Тогда пакеты будут нести достаточную индивидуальную информацию,
> а pkglist-ы -- отражать достаточную совокупную на момент генерации.
> (мысль высказана led@ и мне кажется разумной)

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

В общем с моей точки зрения тут лучше не философствовать насчёт сущностей,
а рассуждать с точки зрения сохранения гарантий.  Получим ли мы всегда
то же самое, если мы применим оптимизацию?  Да, эмпирически при установке
и обновлении пакетов мы всегда получаем то же самое.  Значит, оптимизация
корректна.

А то можно договориться до того, что, например, в gcc нельзя инлайнировать
функции.  Потому что функции несут индвивидуальную информацию.

А выгоды от оптимизации довольно-таки ощутимы.

$ rpm -qR gcc4.5-c++
gcc4.5 = 4.5.1-alt8
libstdc++4.5-devel = 4.5.1-alt8
rpmlib(PayloadIsLzma)
$

> Если вырезать из самих пакетов -- очень большой шанс напороться
> на ещё более неприятные грабли с разрывом цепочки, чем уже
> предсказанные и происшедшие с BuildRequires (см. тж. buildreq -u):
> http://lists.altlinux.org/pipermail/devel/2007-March/137289.html

Если пакет A строго требует пакеты B и C, а пакет B строго требует пакет C,
то удаление из пакета A зависимости на пакет С логически ничего не меняет:
а именно, сохраняется гарантия, что при установке или обновлении пакета A
будет установлен пакет C, как если бы он был напрямую указан в
зависимостях пакета A.

Другими словами, rpm работает правильно, а грабли в других местах -
это грабли в других местах.