On Sat, Jan 26, 2013 at 04:35:37PM +0400, Alexey Gladkov wrote:
> 26.01.2013 16:08, Dmitry V. Levin wrote:
> > Разве это не очевидно?  Вы же не первый год в теме, и знаете, что
> > одновременная установка подпакета одной версии с подпакетом другой версии
> > чревата большими неприятностями, такие смешанные установки вряд ли кто-то
> > в состоянии полноценно протестировать, поэтому лучшее, что мы можем
> > сделать - это избегать их.
> 
> Это не очевидно.

Это не вполне тривиально, но все равно очевидно.

> Нестрогие зависимости это инструмент. Он не может быть хорош или плох.

Нестрогие зависимости редко когда инструмент, чаще это свойство.

> Любой инструмент если его неправильно применять будет приносить вред.
> Стоит ли бороться с неправильным применением того или иного
> инструмента? Конечно да. Нужно ли из-за потенциального вреда запрещать
> инструмент? Мне кажется, что нет.
> 
> Ты можешь привести конкретный пример из сизифа (как ты любишь), где
> нестрогая зависимость вызывает проблемы ?

Ты думаешь, что это умозрительная проблема?  Я несколько дней назад
посмотрел, что это за нечеткие зависимости в 659 исходных пакетах.
Там около процента альтернативных провайдеров типа vim-X11-* и
apache2-httpd-*, и очень много типовых ошибок упаковки, например,
нестрогая зависимость на используемую библиотеку (в пакете нет зависимости
вообще, а нестрогую зависимость на библиотеку вычислил find-requires).
В этой ситуации сложнее привести пример, когда отсутствие строгой
зависимости не создает проблемы точечного обновления.  set-versions
отслеживает только имена функций, этого не всегда бывает достаточно,
на эту тему висят баги:
https://bugzilla.altlinux.org/show_bug.cgi?id=28383
Если обновить библиотеку, в которой не поменялся soname, но не обновить
devel-пакет (таких возможностей сейчас очень много), то можно получить
devel-пакет, в котором API не соответствует ABI в библиотеке.

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

> >> Мы все доказываем и обосновываем тебе, что они нужны.
> > 
> > Нет, вы не доказываете.
> 
> Так ты тоже ещё ничего не доказал. Выше ты написал, что это очевидно.
> Но этот тред показывает, что для людей "не первый год в теме"
> полезность такого запрета совсем не очевидна. Поэтому, думаю,
> доказательство необходимости запрета всё-таки нужно (с плюсами и
> минусами).

Необходимость запрета очевидна, неочевидна необходимость тотального
запрета. :)

> >  Я знаю, что такие ситуации
> > теоретически возможны, и тоже могу сочинить демонстрационный пример.
> 
> Раз ты знаешь, что в таком механизме может быть необходимость, то
> почему не оставляешь возможности для него ?

Я оставляю возможность такого механизма.

> > Но на практике в Сизифе таких примеров либо нет совсем, либо их настолько
> > мало, что я за два дня не нашел.  Помогите мне, найдите этот реальный
> > пример, тогда я верну механизм %_allowed_nonstrict_interdeps.
> 
> И всё-таки давай вернёмся к osec. Пока есть хотя бы один пакет общее
> правило не применимо. Пока ты упорно игнорируешь этот случай.

osec мы с тобой обсуждаем в соседнем треде. :)


-- 
ldv