[devel] JFYI: kernel modules build on git.eter

[Evgeny Sinelnikov]

23 июля 2011 г. 12:26 пользователь Dmitry V. Levin <ldv at altlinux.org>написал:

> On Sat, Jul 23, 2011 at 04:20:48AM +0400, Evgeny Sinelnikov wrote:
> > 23 июля 2011 г. 3:24 пользователь Dmitry V. Levin написал:
> > > On Sat, Jul 23, 2011 at 12:22:34AM +0400, Evgeny Sinelnikov wrote:
> > > > 22 июля 2011 г. 23:56 пользователь Dmitry V. Levin написал:
> > > [...]
> > > > > В любой части спекфайла может встретиться вычисление выражения,
> которое
> > > > > приведет к исполнению произвольного shell-кода при запуске rpm
> > > --specfile.
> > > > >
> > > > Я предлагаю их исключить при вычислении NVR всё лишнее.
> > >
> > > Это сложно.  Вы либо теряете поддержку вполне легальных конструкций,
> > > либо сохраняете поддержку исполнения произвольного shell-кода.
> > >
> > В общем случае, это так, но gear всё равно ограничивает возможности и не
> > подставляет всё. Так что мы, в любом случае, ограничены тем, что может
> > раскрыть gear --describe. Думаю, этим подмножеством и можно ограничиться.
> >
> > > По шаблонам kernel-модулей можно, наверное, договориться и привести
> > > их все к простому виду, который легко парсится без помощи rpm.
>
> Об этом и речь.  Если мы соглашаемся не использовать в спек-файлах
> шаблонов kernel-модулей конструкций, которые не обрабатывает gear, то,
> с одной стороны, обрабатывать такие шаблоны будет проще, но, с другой
> стороны, мы лишаем себя возможности использовать всю полноту языка
> rpm-спекфайлов.
>

 Я подразумевал общий вариант. Хотя речь сейчас идёт о сборке модулей, у
меня есть аналогичный механизм по пересборке пакетов из бранчей. Там тоже
используется add_changelog.

Вкратце, этот вариант (ssh git.eter task add [id] branch [master])
позволяет:
- не делать специальные коммиты для увеличения релизов (релизы увеличиваются
автоматически на основании текущего в репозитории);
- не делать подписанные теги (тег делает сам girar), что упрощает частую
пересборку и необходимый порог для начала работы со сборочной системой
(пересобирающему вообще можно не иметь gpg-подписи);
- узнавать о коммите, на котором собран пакет из changelog, куда его
вписывает girar, при увеличении релиза, как раз с помощью add_changelog;
- получать оригинальную историю, при этом дополнительный коммит в не входит
в сохраняемую после сборки историю пакета.

В общем случае, я думаю, что стоит упростить girar-stamp-spec, до вычисления
S:V-R в ограничениях соотвествующих ограничениям gear --describe.


-- 
Sin (Sinelnikov Evgeny)
Etersoft
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20110723/fb19a205/attachment-0001.html>