On Mon, Feb 07, 2011 at 02:55:09AM +0300, Alexey Tourbin wrote:
> Зависимости устроены по принципу
> 
> %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?

Теоретически возможно установить другой libkdegames4, у которого нет
строгой зависимости на %name-common = %version-%release; если бы можно
было предположить, что у всех мыслимых сборок libkdegames4 всегда есть эта
строгая зависимость, то да, можно проставить строгую зависимость на
libkdegames4 = %version-%release.

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

Если бы пакет честно назывался не libgcc4.5, а libgcc_s1 по имени soname,
то никаких нестрогих зависимостей не потребовалось бы.

> Такая конструкция
> позволит сосуществовать старому компилятору gcc4.5 с новой библиотекой
> libgcc4.6.  Этот класс случаев, когда зависимость на имя пакета
> с библиотекой уже есть, но она специально не строгая, легко учитывать
> автоматически.

Да, наверное.


-- 
ldv