[d-kernel] kernel CVS -> GIT

[d-kernel] kernel CVS -> GIT

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]

Hello!

В git://git.altlinux.org/people/vsu/packages/kernel-build-scripts.git
в ветке modules-in-git выложен вариант скриптов, где шаблоны модулей
хранятся в GIT вместо CVS, а сгенерированные spec-файлы могут также
помещаться в GIT для последующей сборки через gear (например, с
помощью давно обещанной сборочной системы, использующей в качестве
исходных данных GIT-репозитории вместо src.rpm).

В текущем варианте предполагается, что все шаблоны хранятся в общем
репозитории в ветках template/MODULE/DISTRIBUTION, где MODULE - имя
модуля, DISTRIBUTION - ветка для дистрибутива (sisyphus, alt-linux-4.0
и т.п.).  Окончательные пакеты для сборки коммитятся в ветки
kernel-modules-MODULE-FLAVOUR/DISTRIBUTION, кроме того, на них
ставятся теги kernel-modules-MODULE-FLAVOUR/VERSION-RELEASE (что
соответствует формату @name@/@version@-@release@ для gear-create-tag).
История шаблонов из kernel CVS, преобразованная в GIT, выложена в
git://git.altlinux.org/people/vsu/packages/kernel-modules.git (всё,
что было в CVS, включая устаревшие модули).

Неудобство по сравнению с CVS - без использования дополнительных
средств можно одновременно иметь в рабочей копии шаблон только для
одного модуля.  Чтобы держать рядом несколько шаблонов, придётся либо
наплодить кучу репозиториев и производить push/pull между ними, либо
использовать скрипт git-new-workdir, позволяющий создать рабочую
копию, ссылающуюся на репозиторий из другого места (в пакетах git-*
этого скрипта нет - в исходниках git он лежит в contrib/workdir/).

Принимаются предложения по поводу переименования скриптов buildkernel
и buildmodules во что-то, что можно положить в /usr/bin и запаковать в
пакет kernel-build-tools.

-- 
Sergey Vlasov

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] kernel CVS -> GIT

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

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).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] kernel CVS -> GIT

[Konstantin A. Lepikhov]

Hi Sergey!

Tuesday 20, at 08:43:51 PM you wrote:

> 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).
Ух. Сергей, чтобы дать комментарии по этим новшествам, их надо сначала
осмыслить :) Думаю, что-то сказать смогу только в конце недели.

-- 
WBR et al.

Re: [d-kernel] kernel CVS -> GIT

[Anton Farygin]

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 файлами в 
рамках одного репозитария ?

а то как-то страшновато получается...

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

Re: [d-kernel] kernel CVS -> GIT

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]

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.

> а то как-то страшновато получается...

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

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

Ну придумайте что-то получше...

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] kernel CVS -> GIT

[Andrew Stepanov]

Konstantin A. Lepikhov wrote:
> Hi Sergey!
> 
> Tuesday 20, at 08:43:51 PM you wrote:
> 
>> 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).
> Ух. Сергей, чтобы дать комментарии по этим новшествам, их надо сначала
> осмыслить :) Думаю, что-то сказать смогу только в конце недели.
> 

Мысли в слух.

Репозитарий kernel-modules.git хранит модули шаблонов и содержит 270 
веток. Ослепляет :)

Исходные коды внешних модулей поставляют другие мантейнеры.
А собирает все модули один человек. Иногда даже их дотачивает.
И имет налаженную связь с этими самыми мантейнерами внешних модулей.

Для мантейнеров хорошо: они только исходный код дают, а их бинарный 
модуль появляется во всех вариация ядра. Не нужно пинать мантейнеров, 
чтоб собирали модуль для обновившегося ядра. Скомпилируют за тебя.

И следуют заметить, что все модули для разных версий ядер, модификаций 
репозитариев, итд собирает один человек! (Репозитарий kernel-modules.git 
он же один?)

Например: alt-linux-3.0, alt-linux-4.0, Sisyphus.

А если кому-то понадобится не стандартное ядро, а с какой-то фенечкой?

Ну надо будет для кого-то трах-те-бе-дох....

Вопросы:

1. Обновлять репозиторий с шаблонами может мантейнер внешнего модуля?

2. Цитата: >>> Окончательные пакеты для сборки коммитятся в ветки
 >>>kernel-modules-MODULE-FLAVOUR/DISTRIBUTION....
Это что за пакеты такие?
Это пакет типа:
kernel-modules-alsa-std-smp-1.0.15-alt1.132631.1.src.rpm
или пакет типа:
kernel-source-alsa-1.0.15-1.0.15-alt1.src.rpm
Нету же правил для мантейнеров внешних модулей как им вести свой модуль.

Re: [d-kernel] kernel CVS -> GIT

[Andrew Stepanov]

Sergey Vlasov wrote:
> кроме того, на них
> ставятся теги kernel-modules-MODULE-FLAVOUR/VERSION-RELEASE (что
> соответствует формату @name@/@version@-@release@ для gear-create-tag).

Это что тот кто должен собрать свою модификацию ядра (FLOVOUR)
должен понаставлять тегов?

Да и так страшно становится когда скажешь :
$ git-tag в kernel-modules.git где-то через годик

Re: [d-kernel] kernel CVS -> GIT

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2684 bytes --]

On Wed, Nov 21, 2007 at 05:38:04PM +0300, Andrew Stepanov wrote:
> Репозитарий kernel-modules.git хранит модули шаблонов и содержит 270 
> веток. Ослепляет :)

На самом деле существенная часть этих веток уже не нужна (хотя всё
равно их довольно много).

> Исходные коды внешних модулей поставляют другие мантейнеры.
> А собирает все модули один человек. Иногда даже их дотачивает.
> И имет налаженную связь с этими самыми мантейнерами внешних модулей.
> 
> Для мантейнеров хорошо: они только исходный код дают, а их бинарный 
> модуль появляется во всех вариация ядра. Не нужно пинать мантейнеров, 
> чтоб собирали модуль для обновившегося ядра. Скомпилируют за тебя.

Предыдущая система сборки отличалась не сильно - шаблоны лежали в
kernel CVS, мантейнер ядра точно так же пересобирал все модули при
обновлении ядра.

> И следуют заметить, что все модули для разных версий ядер, модификаций 
> репозитариев, итд собирает один человек! (Репозитарий kernel-modules.git 
> он же один?)

Не обязательно - никто не мешает выложить свой репозиторий с нужными
изменениями и попросить их оттуда смержить.  Правда, тут появляется
потенциальная проблема - если при использовании CVS текущие версии
шаблонов для всех модулей лежали в одном месте, в случае GIT в том
виде, как сделано на git.alt, мантейнеру ядра придётся собирать свежие
версии по всему /people/*/packages.  Вероятно, придётся добавить ещё
кучку скриптов для упрощения этой операции.

> Например: alt-linux-3.0, alt-linux-4.0, Sisyphus.
> 
> А если кому-то понадобится не стандартное ядро, а с какой-то фенечкой?
> 
> Ну надо будет для кого-то трах-те-бе-дох....

Модули собираются так же, как и раньше, только вместо cvs нужно будет
забрать git-репозиторий с шаблонами.

> Вопросы:
> 
> 1. Обновлять репозиторий с шаблонами может мантейнер внешнего модуля?

Только путём выкладывания своего варианта в доступное место - на
git.alt не предусмотрена возможность непосредственного доступа разных
пользователей к одному репозиторию.

> 2. Цитата: >>> Окончательные пакеты для сборки коммитятся в ветки
>  >>>kernel-modules-MODULE-FLAVOUR/DISTRIBUTION....
> Это что за пакеты такие?
> Это пакет типа:
> kernel-modules-alsa-std-smp-1.0.15-alt1.132631.1.src.rpm

Да, это именно такие пакеты.  Все эти перестановки были затеяны из-за
обещанного перехода на заливку пакетов через git, а не src.rpm.

> или пакет типа:
> kernel-source-alsa-1.0.15-1.0.15-alt1.src.rpm

Для пакетов kernel-source-* пока ничего не меняется (хотя в случае,
если src.rpm всё-таки будут упразднены, можно будет избавиться и от
этих пакетов, поместив исходники непосредственно в шаблоны модулей).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] kernel CVS -> GIT

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

On Wed, Nov 21, 2007 at 05:53:45PM +0300, Andrew Stepanov wrote:
> Sergey Vlasov wrote:
> > кроме того, на них
> > ставятся теги kernel-modules-MODULE-FLAVOUR/VERSION-RELEASE (что
> > соответствует формату @name@/@version@-@release@ для gear-create-tag).
> 
> Это что тот кто должен собрать свою модификацию ядра (FLOVOUR)
> должен понаставлять тегов?

Подозреваю, что для использования ssh git.alt build (если это в конце
концов заработает) такие теги будут обязательны.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [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: не придумал.