[devel] JFYI: kernel modules build on git.eter
Evgeny Sinelnikov
sin на altlinux.ru
Сб Июл 23 16:27:20 UTC 2011
23 июля 2011 г. 20:17 пользователь Evgeny Sinelnikov <sin at altlinux.ru>написал:
>
>
> 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;
> - получать оригинальную историю, при этом дополнительный коммит в не входит
> в сохраняемую после сборки историю пакета.
>
Да, я там ввёл ещё такую возможность, как вставка суффикса для бранча, в
итоге бекпортирование выглядит совершенно тривиально и не требует никаких
действий вообще.
$ ssh git.eter rebuild -b p5 /projects/asu/uniset
$ ssh git.eter rebuild -b 5.1 /projects/asu/uniset
$ ssh git.eter rebuild -b 5.0 /projects/asu/uniset
и мы получаем:
$ ls /var/ftp/pub/Etersoft/LINUX at Etersoft/*/*/files/i586/RPMS/libuniset-1.0-alt*.Build*.i586.rpm
/var/ftp/pub/Etersoft/LINUX at Etersoft
/5.0/branch/files/i586/RPMS/libuniset-1.0-alt41.M50.42.Build2.i586.rpm
/var/ftp/pub/Etersoft/LINUX at Etersoft
/5.1/branch/files/i586/RPMS/libuniset-1.0-alt41.M51.42.Build2.i586.rpm
/var/ftp/pub/Etersoft/LINUX at Etersoft
/p5/branch/files/i586/RPMS/libuniset-1.0-alt41.M50P.42.Build2.i586.rpm
> В общем случае, я думаю, что стоит упростить 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/6281d323/attachment.html>
Подробная информация о списке рассылки Devel