26.01.2013 17:32, Dmitry V. Levin пишет: > On Sat, Jan 26, 2013 at 04:35:37PM +0400, Alexey Gladkov wrote: >> 26.01.2013 16:08, Dmitry V. Levin wrote: >>> Разве это не очевидно? Вы же не первый год в теме, и знаете, что >>> одновременная установка подпакета одной версии с подпакетом другой версии >>> чревата большими неприятностями, такие смешанные установки вряд ли кто-то >>> в состоянии полноценно протестировать, поэтому лучшее, что мы можем >>> сделать - это избегать их. >> >> Это не очевидно. > > Это не вполне тривиально, но все равно очевидно. Это далеко не очевидно. Для меня очевидно обратное, когда речь идёт о внутрипакетных зависимостях подпакетов с конфигами (вариантами конфигурации чего либо) и модулями -- и в том и в другом случаи для меня очевидна ценность возможностей: а) обновить только заданный подпакет, не трогая остальное; б) поставить подпакет на hold и обновить остальное; в) заменить подпакет его альтернативой, собранной из другого источника. Да, этими возможностями можно пользоваться не всегда: изменения интерфейса работы с модулями (его ABI) и инфраструктурные изменения в подсистемах могут приводить к нерабочим конфигурациям. Но такие конфигурации можно отстрелить вдумчивой расстановкой Provides/Conflicts/Requires и указанием зависимостей на файлы/каталоги. > >> Нестрогие зависимости это инструмент. Он не может быть хорош или плох. > > Нестрогие зависимости редко когда инструмент, чаще это свойство. В моих пакетах это именно инструмент. И ручная работа над Provides/Conflicts/Requires и файловыми зависимостями (с соответсвующей потерей времени) -- плата за его применение. Прошу указать когда его применение к моим пакетам приводило к проблемам, в виде неработоспособности пакета из-за рассинхронизации его компонент. (По моему у меня уже давно такого не было.) > >> Любой инструмент если его неправильно применять будет приносить вред. >> Стоит ли бороться с неправильным применением того или иного >> инструмента? Конечно да. Нужно ли из-за потенциального вреда запрещать >> инструмент? Мне кажется, что нет. >> >> Ты можешь привести конкретный пример из сизифа (как ты любишь), где >> нестрогая зависимость вызывает проблемы ? > > Ты думаешь, что это умозрительная проблема? Я несколько дней назад > посмотрел, что это за нечеткие зависимости в 659 исходных пакетах. > Там около процента альтернативных провайдеров типа vim-X11-* и > apache2-httpd-*, Сделанных мантейнерами _руками_, под их ответственность. Именно для них и нужна ручка, применение которой будет говорить о том, что мантейнер _знает_ что именно он делает (или что он считает что это так). > и очень много типовых ошибок упаковки, например, > нестрогая зависимость на используемую библиотеку (в пакете нет зависимости > вообще, а нестрогую зависимость на библиотеку вычислил find-requires). Здесь автозамена зависимостей на строгие нужна. > В этой ситуации сложнее привести пример, когда отсутствие строгой > зависимости не создает проблемы точечного обновления. set-versions > отслеживает только имена функций, этого не всегда бывает достаточно, > на эту тему висят баги: > https://bugzilla.altlinux.org/show_bug.cgi?id=28383 > Если обновить библиотеку, в которой не поменялся soname, но не обновить > devel-пакет (таких возможностей сейчас очень много), то можно получить > devel-пакет, в котором API не соответствует ABI в библиотеке. Между devel-пакетом и соответствующей ему библиотекой -- тоже. > > Так что это не просто неряшливые спеки приводят к неряшливым пакетам, > а еще и неряшливые пакеты - к проблемам точечных обновлений, которых можно > избежать с помощью строгих внутрипакетных зависимостей. Согласен полностью! Но не стоит под эту гребёнку вести случаи, где нестрогие зависимости мантейнер расставлял сам, руками!!! > >>>> Мы все доказываем и обосновываем тебе, что они нужны. >>> >>> Нет, вы не доказываете. >> >> Так ты тоже ещё ничего не доказал. Выше ты написал, что это очевидно. >> Но этот тред показывает, что для людей "не первый год в теме" >> полезность такого запрета совсем не очевидна. Поэтому, думаю, >> доказательство необходимости запрета всё-таки нужно (с плюсами и >> минусами). > > Необходимость запрета очевидна, неочевидна необходимость тотального > запрета. :) 1. Очевидна _безусловная_ необходимость запрета для связки библиотеки и её devel пакет. Возможно даже не только для библиотек, а вообще для всех подпакетов, требующихся для собираемого devel пакета. 2. Возможно полезен (но всё таки не очевиден) безусловный запрет нестрогих зависимостей для подпакетов связвнных через set-versions. 3. Очевиден вред от безусловного запрета нестрогих зависимостей для того что не попадает под пункты 1-2. Это конфиги, части не входящие в ядро пакета, но собираемые из одного источника (такие как модули) и пр. подобное. 3десь очевидна нужность нужен запрета по умолчанию, с возможностью его _ручного_ отключения. > >>> Я знаю, что такие ситуации >>> теоретически возможны, и тоже могу сочинить демонстрационный пример. >> >> Раз ты знаешь, что в таком механизме может быть необходимость, то >> почему не оставляешь возможности для него ? > > Я оставляю возможность такого механизма. Т. е. ручка всё таки будет? УРА!!! :-) > >>> Но на практике в Сизифе таких примеров либо нет совсем, либо их настолько >>> мало, что я за два дня не нашел. Помогите мне, найдите этот реальный >>> пример, тогда я верну механизм %_allowed_nonstrict_interdeps. >> >> И всё-таки давай вернёмся к osec. Пока есть хотя бы один пакет общее >> правило не применимо. Пока ты упорно игнорируешь этот случай. > > osec мы с тобой обсуждаем в соседнем треде. :) -- С уважением. Алексей.