On Fri, Jan 25, 2013 at 04:54:36PM +0200, Led wrote:
> On Friday 25 January 2013 15:01:14 Aleksey Avdeev wrote:
> > 25.01.2013 16:51, Dmitry V. Levin пишет:
> > > On Fri, Jan 25, 2013 at 04:39:39PM +0400, Aleksey Avdeev wrote:
> > >> 25.01.2013 16:32, Dmitry V. Levin пишет:
> > >>> 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.
> > >>
> > >> 1. Что произойдёт, если в репозитории есть другой пакет С (не являющийся
> > >> под пакетом данного исходного S) который тоже предоставляет зависимость
> > >> X?
> > >
> > > Такой пакет С не будет приниматься в рассмотрение этим алгоритмом.
> >
> >   И получается подмена зависимости на функционал -- жёсткой привязкой к
> > апстримнуму комплекту...
> 
> Вот именно. Нередкий случай, когда пакет предоставляет какой-то минимальный 
> функционал, вынесенный в субпакет, а более "навороченныц" вариант 
> предоставляется совершенно другим пакетом (собираемым отдельно). Или наборот.

Нередкий?  Хотя бы один реальный пример можно привести?


-- 
ldv