Re: [devel] kde4games & dep optimizations

[Alexey Tourbin <at@altlinux.ru>]

On Mon, Feb 07, 2011 at 12:27:02AM +0300, Dmitry V. Levin wrote:
> On Sun, Feb 06, 2011 at 06:31:15AM +0300, Alexey Tourbin wrote:
> > Интересно, что тогда дальше делать?  С одной стороны, следовало бы
> > исправить такие пакеты (для этого нужно сначала научиться их
> > диагностировать).  С другой стороны, если мейнтейнерам это в голову не
> > приходит, то может лучше научить rpm автоматически вставлять строгие
> > зависимости туда, где они будут иметь смысл?
> 
> Для того, чтобы проставлять такие зависимости автоматически, нужно
> - научиться диагностировать нехватку таких зависимостей;

Я ещё раз проверил зависмости kde4games, там всё не так глупо.

$ hsh-run -- rpm -e --test kde4games-common
error: removing these packages would break dependencies:
        kde4games-common = 4.5.5-alt1 is needed by kde4games-core-4.5.5-alt1
        kde4games-common = 4.5.5-alt1 is needed by libkdegames4-4.5.5-alt1
$

Зависимости устроены по принципу

%package common
%package -n libkdegames4
Requires: %name-common = %version-%release
%package game1
Requires: %name-common = %version-%release
%package game2
Requires: %name-common = %version-%release
...
%package gameN
Requires: %name-common = %version-%release

То есть, с одной стороны, все зависимости вроде бы строгие.  С другой
стороны, строгой цепочки от kde4games-gameN к libkdegames4 нет.
Смысл этого феномена мне ещё не сосем понятен.  Нельзя ли из всего
этого каким-то образом заключить, что можно добавить (или "усилить")
строгую зависимость на libkdegames4?

> - выдать packager'ам интерфейс для отключения новой автоматики в случае,
>   если она принимает неправильное решение.

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

Мне пока известно всего одно необходимое и разумное исключение из этого
правила: пакет gcc4.5 требует libgcc4.5 >= 4.5.1-alt7.  Такая конструкция
позволит сосуществовать старому компилятору gcc4.5 с новой библиотекой
libgcc4.6.  Этот класс случаев, когда зависимость на имя пакета
с библиотекой уже есть, но она специально не строгая, легко учитывать
автоматически.