[devel] non-strict deps Зачем?

Сб Янв 26 22:55:33 MSK 2013

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 мы с тобой обсуждаем в соседнем треде. :)

-- 

С уважением. Алексей.

----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 900 байтов
Описание: OpenPGP digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20130126/8621d332/attachment-0001.bin>