[d-kernel] kernel CVS -> GIT

[Anton Farygin]

Sergey Vlasov пишет:
> On Wed, Nov 21, 2007 at 02:57:28PM +0300, Anton Farygin wrote:
>> Sergey Vlasov пишет:
>>> On Mon, Nov 19, 2007 at 11:28:38PM +0300, Sergey Vlasov wrote:
>>>> История шаблонов из kernel CVS, преобразованная в GIT, выложена в
>>>> git://git.altlinux.org/people/vsu/packages/kernel-modules.git (всё,
>>>> что было в CVS, включая устаревшие модули).
>>> Вот теперь то, что было выложено, ещё и собирается (после добавления
>>> файлов .gear/rules).
>> Серёг, а не проще ли научить gear работать с несколькими spec файлами в 
>> рамках одного репозитария ?
> 
> Вероятно, имелось в виду "в рамках одного бранча" (поскольку
> репозиторий и так уже один)?  Это в gear уже есть, причём в двух
> вариантах - либо через -r RULES указать другой файл с правилами (в
> котором будет ссылка на spec), либо через -t COMMIT:PATH задать поиск
> .gear/rules и всего прочего в нужном подкаталоге.  Но в этом случае
> для сборки из git недостаточно будет передать просто подписанный тег,
> указывающий на нужный коммит - вместе с ним нужно будет как-то
> передавать требуемое значение RULES или PATH.

в идеале конечно - запатчить gear-rules для возможности искать spec 
файлы в разных каталогах одного бранч'а.

Тогда всё будет решено на уровне установки одного тэга - версии ядра.

Правда там ещё вылезает вопрос - а что собственно делать в том случае, 
когда один модуль зависит от другого по сборке ?

> 
>> а то как-то страшновато получается...
> 
> Да, бранчей получается куча (хотя можно немного разгрести свалку,
> окончательно выбросив устаревшие модули и бранчи для старых
> дистрибутивов, которые сейчас были туда засунуты автоматом).  С другой
> стороны, если всё засунуть в один бранч, история разных модулей
> смешивается в одну кучу, что плохо согласуется с ситуацией, когда у
> модулей разные мантейнеры.

Видимо это всё равно будет так (и в CVS оно было в таком же виде). 
Ничего страшного в истории не вижу.

> 
>> Хотя в принципе вполне юзабельно, но всё-равно как-то напрягает - 
>> действий по сборке ядра становится больше ? или нет ?
> 
> Ну придумайте что-то получше...

Думаем, но пока ничего лучше чем запатчить gear на предмет работы с 
несколькими spec: не придумал.