[devel] I: repocop NMU

Dmitry V. Levin ldv на altlinux.org
Пт Янв 25 16:17:27 MSK 2013


On Fri, Jan 25, 2013 at 03:11:31PM +0300, Aleksey Novodvorsky wrote:
> 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, при небольшой ошибке в
> маленьком подпакете, придетеся все пересобирать вместе заново, что
> вряд ли разумно для нестабильного бранча. Для стабильного --да, имеет
> смысл.
> Результатом жестких мер может быть торможение динамики развития Сизифа.

Алексей, речь идет о внутрипакетных зависимостях, каким образом это может
повлиять на потребность "все пересобирать вместе заново"?


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


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