[devel] I: repocop NMU

Aleksey Novodvorsky aen на altlinux.ru
Пт Янв 25 16:11:31 MSK 2013


25 января 2013 г., 15:58 пользователь Aleksey Avdeev
<solo на solin.spb.ru> написал:
> 25.01.2013 15:34, Dmitry V. Levin пишет:
>> On Fri, Jan 25, 2013 at 03:07:36PM +0400, Aleksey Avdeev wrote:
>>> 25.01.2013 14:53, Dmitry V. Levin пишет:
>>> ...
>>>> Проанализировав множество нестрогих внутрипакетных зависимостей, которые
>>>> диагностирует rpm-build, я пришел к выводу, что среди них выделяется
>>>> только один класс зависимостей, которые нужно сохранить,
>>>> а все остальные следует сделать строгими.
>>>>
>>>> Я сейчас тестирую rpm-build, который автоматически добавляет строгие
>>>> внутрипакетные зависимости во всех случаях, в которых это необходимо.
>>>> Так что я надеюсь, что NMU от repocop в аварийном режиме не потребуется,
>>>> да и сам NMU будет технически проще.
>>>
>>>   _Отключить_ этот механизм можно?!!
>>
>> Пока не вижу смысла отключать этот механизм.
>
>   Усложнение работы мантейнера: теперь для обеспечения возможности
> точечного обновления модулей (или возможности поставить их на холд),
> распространяемых апстримом комбайна (такого как apache* или moodle*)
> придётся выносить модули в отдельный пакет (не подпакет) и собирать
> отдельно.
>
> PS: Грубо говоря, тупая замена нестрогих зависимостей на строгие
> превращает модульные комбайны в монолиты, строго синхронизируя по
> версиям их части, распространяемые апстримом в рамках одного
> дистрибутива. При этом, например, апстримы moodle и eGroupWare обратную
> совместимость хранилищ, используемых модулями, иногда ломают (натыкался
> на такое). При этом стандартная рекомендация -- использовать модуь от
> предыдущий версии, т. е. поставить его на холд, в нашем случаи. Теперь
> такой вариант отпадает: при постановки модуля на холд будет блокировано
> обновление всего остального монстра (т. к. строгая зависимость %VER)...
>

По крайней мере, стоит подумать о возможности упрощения тестовых
сборок или даже сборок с небольшими фиксами.
Например, в случае такого монстра как kde4, при небольшой ошибке в
маленьком подпакете, придетеся все пересобирать вместе заново, что
вряд ли разумно для нестабильного бранча. Для стабильного --да, имеет
смысл.
Результатом жестких мер может быть торможение динамики развития Сизифа.

Rgrds, Алексей

> --
>
> С уважением. Алексей.
>
>
>
> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel


Подробная информация о списке рассылки Devel