On Fri, Jan 25, 2013 at 04:32:49PM +0400, Dmitry V. Levin wrote:
> On Fri, Jan 25, 2013 at 04:13:23PM +0400, Alexey Gladkov wrote:
> > 25.01.2013 14:53, Dmitry V. Levin wrote:
> > > Проанализировав множество нестрогих внутрипакетных зависимостей, которые
> > > диагностирует rpm-build, я пришел к выводу, что среди них выделяется
> > > только один класс зависимостей, которые нужно сохранить,
> > > а все остальные следует сделать строгими.
> > 
> > Можно ли рассказать подробнее т.к. меня это касается?
> 
> Тестируется следующий алгоритм: подпакет A исходного пакета S
> автоматически получает строгую зависимость на подпакет B исходного
> пакета S, если у подпакета A есть такая зависимость X, что подпакет B
> является единственным подпакетом исходного пакета S, удовлетворяющим
> эту зависимость X.

Насколько я понимаю, описанный выше алгоритм преобразования
зависимостей сработает в следующей ситуации:

%package -n A
Requires: X

%package -n B
Provides: X

(и нет других подпакетов с Provides: X)

В результате подпакет A вместо зависимости на виртуальный пакет X
должен получить зависимость вида B = %EVR ?

На мой взгляд, это неправильно - если в зависимости явно указано имя
виртуального пакета, скорее всего, это сделано намеренно, и такую
зависимость необходимо оставлять в том виде, как она есть.  А вот
зависимость вида Requires: B, где B - имя реального подпакета,
действительно стоит автоматически дополнять "= %EVR" (естественно,
учитывая, что у подпакета может присутствовать собственный тег
Version: или Release:).

Пример реально существующего в Сизифе пакета, который сломается при
введении предлагаемого алгоритма - xboard, где в основном пакете
указано Requires: xboard-theme, а также собирается единственный
подпакет xboard-theme-default, имеющий Provides: xboard-theme, но при
этом в репозитории присутствуют и несколько отдельных пакетов
xboard-theme-*, также предоставляющих xboard-theme.