[devel] Угрозы развитию дистрибутива. Пути решения: gear-subsystem

Paul Wolneykien manowar на altlinux.org
Вт Окт 4 18:33:58 UTC 2011


04.10.2011 21:50, Денис Смирнов пишет:
> On Tue, Oct 04, 2011 at 09:38:50PM +0400, Paul Wolneykien wrote:
>
> PW>     Идея в том, чтобы совершать действия не с отдельным пакетом, а с
> PW>  группой пакетов — подсистемой ­— как с единым целым. Я представляю что
> PW>  подсистема — это:
> PW>     1. список gear-репозиториев, из которых собираются пакеты;
> PW>     2. сценарий для вычисления и сортировки набора всех требующих
> PW>  обновления пакетов;
> PW>     3. сценарий — единая точка входа для обновления версий и истории
> PW>  изменения в каждом из требующих обновления пакетов.
> PW>     Хранить информацию о наборе gear (git)-репозиториев (п. 1.) можно
> PW>  было бы, наверное, используя git-submodule. Тогда главный репозиторий
> PW>  хранил бы в себе пп. 2 и 3. Для выполнения обновления и сборки можно
> PW>  было бы завести команды-обёртки, использующие код пп. 2 и 3. Тогда
> PW>  обновление подсистемы может выглядеть примерно так:
>
> Итого это все равно превратиться в набор сценариев поверх girar-nmu.
>
> PW>     Как-то так. Это должно быть удобно и человеку и роботу (cronbuild).
> PW>  Или нет?
>
> Скажу так -- встроить по крайней мере часть функционала girar-nmu в girar
> было бы полезно. А столь высокоуровневые вещи туда встраивать бесполезно,
> ибо они будут либо слишком ограниченными, либо слишком гибкими (и не
> пройдут требований ldv@ по безопасности и качеству кода).

   А причём тут girar? Он тут уже не причём. Есть просто git-репозиторий 
с подключёнными модулями, некоторый набор скриптов в, предположим, 
.gear/subsystem, и программы-обёртки к ним (gear-subsystem-*). Всё что я 
пока предлагаю, это сделать единую точку входа для обновления версий и 
истории изменения набора связанных пакетов, и для расстановки сборочных 
тегов. Для этого нужен скрипт, умеющий выбирать требующие пересборки 
пакеты (как уже писалось выше, не всегда нужно пересобирать все пакеты). 
Как и в случае с cronbuild-update-source, такой сценарий будет в каждом 
случае свой. Но вот остальную часть механизма можно было бы сделать 
стандартной.

>
> В первом случае окажется что оно пригодно только для небольшого количества
> пакетов, которые прекрасно обойдутся без этого.
>
>
>
>
> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



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