[devel] I: git.altlinux.org: Sisyphus

[devel] I: git.altlinux.org: Sisyphus

[Dmitry V. Levin]

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

Hi,

Все предыдущие письма на тему git.altlinux.org обладали двумя свойствами:
- они описывали то, что уже есть и в целом работает;
- то, о чём шла речь, ещё не было связано непосредственно с Sisyphus.
Теперь я вступаю на зыбкую почву, поскольку речь пойдёт о применении
git.altlinux.org к Sisyphus, т.е. о таком использовании, которое находится
в стадии планирования и разработки.

При обновлении в people/USER/packages/PACKAGE специального тэга-ссылки
refs/releases/sisyphus (я надеюсь, что такой тэг будет удобно делать
с помощью утилиты gear-release) репозиторий с этим тэгом будет ставиться
в очередь на сборку в Сизиф.
Тэг refs/releases/sisyphus может определять имя исходного пакета, который
должен получиться по окончании сборки - эта информация может пригодиться
в случае если имя git-репозитория не совпадает с именем исходного пакета.

Получив из очереди новую порцию информации (user,repository,tag,package),
скрипт проверит, нет ли препятствий к тому, чтобы данный package собирал в
Сизиф указанный user.  Как вариант, можно попробовать сделать эту проверку
интерактивной, т.е. ещё на стадии обновления ссылки refs/releases/sisyphus
в git-репозитории.
Далее, если заявленный пакет уже был собран в Сизиф ранее по этой
схеме, то сохранённый по окончании предыдущей успешной сборки этого
пакета git-репозиторий клонируется, в противном случае создаётся
новый git-репозиторий.
В получившийся репозиторий с git.altlinux.org закачивается новый
refs/releases/sisyphus.  Если предназначенный для сборки commit object
не является наследником того commit object, который был успешно собран
в предыдущий раз, то сборка отменяется.
Далее осуществляется сборка пакета, проводится проверка на соответствие
результата сборки заявленному имени пакета.
Выполняются другие проверки, которые принято проводить с пакетом.
Собранные и проверенные бинарные пакеты отправляются на индексацию для
apt, а git-репозиторий, из которого производилась сборка, публикуется на
git.altlinux.org и используется описанным выше образом для последующих
сборок.
Сводный каталог git-репозиториев успешно собранных пакетов и есть
кэширующий репозиторий Сизифа, о котором я упомянул вчера.


-- 
ldv

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

Re: [devel] I: git.altlinux.org: Sisyphus

[Sergey Vlasov]

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

On Wed, Sep 13, 2006 at 06:39:59PM +0400, Dmitry V. Levin wrote:
> При обновлении в people/USER/packages/PACKAGE специального тэга-ссылки
> refs/releases/sisyphus (я надеюсь, что такой тэг будет удобно делать
> с помощью утилиты gear-release) репозиторий с этим тэгом будет ставиться
> в очередь на сборку в Сизиф.
> Тэг refs/releases/sisyphus может определять имя исходного пакета, который
> должен получиться по окончании сборки - эта информация может пригодиться
> в случае если имя git-репозитория не совпадает с именем исходного пакета.

Как в таком случае организовать одновременную отправку на сборку
нескольких пакетов из одного репозитория?  Например, при сборке нескольких
вариантов ядер, отличающихся только файлом конфигурации (что придётся
делать на i586 как минимум из-за PAE) логично держать эти пакеты в
соседних ветках одного репозитория.  Однако в refs/releases/sisyphus
нельзя указать более одного коммита...

В случае ядра возможен и другой способ - использовать для всех вариантов
ядра, отличающихся файлом конфигурации, одну общую ветку, но иметь в этой
ветке несколько файлов с правилами для gear (и, соответственно, несколько
spec-файлов).  Тогда возникает необходимость передавать через содержимое
тега refs/releases/sisyphus набор путей к файлам правил для gear, которые
нужно использовать.  Кроме того, подобный вариант менее удобен в поддержке
(в частности, изменения, общие для всех вариантов spec-файлов и файлов
конфигурации, придётся копировать из одного варианта в другой вручную; при
использовании отдельных веток в этом может помочь обычный механизм merge).

Или всё это слишком сложно, и придётся делать отдельный репозиторий для
других вариантов ядра только для запуска сборки?

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

Re: [devel] I: git.altlinux.org: Sisyphus

[Alexey Gladkov]

Sergey Vlasov пишет:
> Как в таком случае организовать одновременную отправку на сборку
> нескольких пакетов из одного репозитория?  Например, при сборке нескольких
> вариантов ядер, отличающихся только файлом конфигурации (что придётся
> делать на i586 как минимум из-за PAE) логично держать эти пакеты в
> соседних ветках одного репозитория.  Однако в refs/releases/sisyphus
> нельзя указать более одного коммита...
> 
> В случае ядра возможен и другой способ - использовать для всех вариантов
> ядра, отличающихся файлом конфигурации, одну общую ветку, но иметь в этой
> ветке несколько файлов с правилами для gear (и, соответственно, несколько
> spec-файлов).  Тогда возникает необходимость передавать через содержимое
> тега refs/releases/sisyphus набор путей к файлам правил для gear, которые
> нужно использовать.  Кроме того, подобный вариант менее удобен в поддержке
> (в частности, изменения, общие для всех вариантов spec-файлов и файлов
> конфигурации, придётся копировать из одного варианта в другой вручную; при
> использовании отдельных веток в этом может помочь обычный механизм merge).
> 
> Или всё это слишком сложно, и придётся делать отдельный репозиторий для
> других вариантов ядра только для запуска сборки?

Сейчас в релиз тэге может передаваться имя пакета, релиз тэг может
вешаться на другой тэг или commitish.
Собственно, есть возможность сделать следующее: вешаешь релиз тэг на
бранч с одним пакетом, делаешь git-push ... после этого повторяешь
процедуру для бранча с другим пакетом.

Как тебе такое предложение ?

-- 
Rgrds, legion

Re: [devel] I: git.altlinux.org: Sisyphus

[Sergey Vlasov]

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

On Thu, Nov 09, 2006 at 05:11:44PM +0300, Alexey Gladkov wrote:
> Сейчас в релиз тэге может передаваться имя пакета, релиз тэг может
> вешаться на другой тэг или commitish.
> Собственно, есть возможность сделать следующее: вешаешь релиз тэг на
> бранч с одним пакетом, делаешь git-push ... после этого повторяешь
> процедуру для бранча с другим пакетом.

Т.е., при обновлении refs/releases/sisyphus посылается команда на
пересборку, после чего этот тег уже больше не нужен?  Всё, что нужно,
копируется из репозитория мантейнера в процессе обработки update hook?

> Как тебе такое предложение ?

Можно работать и так...

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

Re: [devel] I: git.altlinux.org: Sisyphus

[Alexey Gladkov]

Sergey Vlasov пишет:
> Т.е., при обновлении refs/releases/sisyphus посылается команда на
> пересборку, после чего этот тег уже больше не нужен?  Всё, что нужно,
> копируется из репозитория мантейнера в процессе обработки update hook?

В update hook можно выяснить sha1 объекта и дальше работать с ним.
Сейчас это не так ... сейчас скрипты передают сборщику именно
refs/releases/* (я имею ввиду не текущего сборщика, а того который
только пишется).

Чтобы реализовать эту схему нужно будет пропатчить git-fetch-pack
чтобы он мог получать объекты по sha1 ... сейчас он умеет получать
только именованные объекты т.е. refs/heads/ или refs/tags/.

> Можно работать и так...

Тебе это будет удобно ?

-- 
Rgrds, legion

Re: [devel] I: git.altlinux.org: Sisyphus

[Sergey Vlasov]

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

On Thu, Nov 09, 2006 at 06:06:28PM +0300, Alexey Gladkov wrote:
> Sergey Vlasov пишет:
> > Т.е., при обновлении refs/releases/sisyphus посылается команда на
> > пересборку, после чего этот тег уже больше не нужен?  Всё, что нужно,
> > копируется из репозитория мантейнера в процессе обработки update hook?
> 
> В update hook можно выяснить sha1 объекта и дальше работать с ним.
> Сейчас это не так ... сейчас скрипты передают сборщику именно
> refs/releases/* (я имею ввиду не текущего сборщика, а того который
> только пишется).

Тогда в этом месте получается race.

> Чтобы реализовать эту схему нужно будет пропатчить git-fetch-pack
> чтобы он мог получать объекты по sha1 ... сейчас он умеет получать
> только именованные объекты т.е. refs/heads/ или refs/tags/.

Попытка сделать это была:

http://thread.gmane.org/gmane.comp.version-control.git/20670/focus=20670

Тогда патч забраковали.

> > Можно работать и так...
> 
> Тебе это будет удобно ?

Удобен будет любой вариант, который позволит не плодить репозитории без
необходимости.

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

Re: [devel] I: git.altlinux.org: Sisyphus

[Alexey Gladkov]

Sergey Vlasov пишет:
>> В update hook можно выяснить sha1 объекта и дальше работать с ним.
>> Сейчас это не так ... сейчас скрипты передают сборщику именно
>> refs/releases/* (я имею ввиду не текущего сборщика, а того который
>> только пишется).
> 
> Тогда в этом месте получается race.

В чём ты видишь race ?

> Попытка сделать это была:
> 
> http://thread.gmane.org/gmane.comp.version-control.git/20670/focus=20670

угу. спасибо. посмотрю.

-- 
Rgrds, legion

Re: [devel] I: git.altlinux.org: Sisyphus

[Dmitry V. Levin]

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

On Thu, Nov 09, 2006 at 06:38:57PM +0300, Sergey Vlasov wrote:
> On Thu, Nov 09, 2006 at 06:06:28PM +0300, Alexey Gladkov wrote:
> > Sergey Vlasov пишет:
> > > Т.е., при обновлении refs/releases/sisyphus посылается команда на
> > > пересборку, после чего этот тег уже больше не нужен?  Всё, что нужно,
> > > копируется из репозитория мантейнера в процессе обработки update hook?
> > 
> > В update hook можно выяснить sha1 объекта и дальше работать с ним.
> > Сейчас это не так ... сейчас скрипты передают сборщику именно
> > refs/releases/* (я имею ввиду не текущего сборщика, а того который
> > только пишется).
> 
> Тогда в этом месте получается race.

В этом месте race отсутствует, поскольку sha1 объекта, на который
ссылается release tag, находится в самом release tag.

Но если release tag после извлечения из него sha1 тэга, по которому будет
выполнена сборка, больше не будет использоваться, это значит, что release
tag будет использоваться только для инициирования процесса сборки.

В таком ракурсе я не вполне уверен, что release tag будет наиболее удобным
способом инициировать процесс сборки.

Не будет ли тогда проще какой-нибудь gear-push-build с синтаксисом,
аналогичным git-push(1)?

Например,
gear-push-build <release> [<repository> [<tag>]]
где
- <release> имеет тот же смысл что и <release-tag> в gear-release;
- <repository> имеет тот же смысл что и в git-push;
- <tag> это имя тэга или commit-ish, для которого существует единственное
  имя тэга, по умолчанию commit-ish это HEAD.

Тогда "gear-push-build sisyphus" отправит на сборку в sisyphus тэг,
ссылающийся на HEAD, по адресу, указанному в $GIT_DIR/remotes/origin.

[...]
> Удобен будет любой вариант, который позволит не плодить репозитории без
> необходимости.

Этот критерий является необходимым но не является достаточным.


-- 
ldv

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

Re: [devel] I: git.altlinux.org: Sisyphus

[Alexey Gladkov]

Dmitry V. Levin пишет:
> В таком ракурсе я не вполне уверен, что release tag будет наиболее удобным
> способом инициировать процесс сборки.
> 
> Не будет ли тогда проще какой-нибудь gear-push-build с синтаксисом,
> аналогичным git-push(1)?

Я попробую сделать.

> Например,
> gear-push-build <release> [<repository> [<tag>]]
> где
> - <release> имеет тот же смысл что и <release-tag> в gear-release;
> - <repository> имеет тот же смысл что и в git-push;
> - <tag> это имя тэга или commit-ish, для которого существует единственное
>   имя тэга, по умолчанию commit-ish это HEAD.
> 
> Тогда "gear-push-build sisyphus" отправит на сборку в sisyphus тэг,
> ссылающийся на HEAD, по адресу, указанному в $GIT_DIR/remotes/origin.

Это хорошая идея, но для её требуется ещё одно из двух: либо ввести
явное ограничение на <tag> ... он должен быть тегом или хэдом, либо
всё-таки пропатчить git на предмет передчи commit-ish.

-- 
Rgrds, legion

Re: [devel] I: git.altlinux.org: Sisyphus

[Dmitry V. Levin]

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

On Fri, Nov 10, 2006 at 11:57:28PM +0300, Alexey Gladkov wrote:
> Dmitry V. Levin пишет:
> > В таком ракурсе я не вполне уверен, что release tag будет наиболее удобным
> > способом инициировать процесс сборки.
> > 
> > Не будет ли тогда проще какой-нибудь gear-push-build с синтаксисом,
> > аналогичным git-push(1)?
> 
> Я попробую сделать.

А стоит ли?  Может быть есть другие точки зрения на вопрос?

> > Например,
> > gear-push-build <release> [<repository> [<tag>]]
> > где
> > - <release> имеет тот же смысл что и <release-tag> в gear-release;
> > - <repository> имеет тот же смысл что и в git-push;
> > - <tag> это имя тэга или commit-ish, для которого существует единственное
> >   имя тэга, по умолчанию commit-ish это HEAD.
> > 
> > Тогда "gear-push-build sisyphus" отправит на сборку в sisyphus тэг,
> > ссылающийся на HEAD, по адресу, указанному в $GIT_DIR/remotes/origin.
> 
> Это хорошая идея, но для её требуется ещё одно из двух: либо ввести
> явное ограничение на <tag> ... он должен быть тегом или хэдом, либо
> всё-таки пропатчить git на предмет передчи commit-ish.

Он так или иначе должен быть тэгом, т.е. либо он сам, либо его
git-describe должен являться именем тэга.  Это нужно для того, чтобы можно
было потом установить, что именно было собрано.


-- 
ldv

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

Re: [devel] Q: gear-push-build

[Dmitry V. Levin]

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

On Sat, Nov 11, 2006 at 12:07:35AM +0300, Dmitry V. Levin wrote:
> On Fri, Nov 10, 2006 at 11:57:28PM +0300, Alexey Gladkov wrote:
> > Dmitry V. Levin пишет:
> > > В таком ракурсе я не вполне уверен, что release tag будет наиболее удобным
> > > способом инициировать процесс сборки.
> > > 
> > > Не будет ли тогда проще какой-нибудь gear-push-build с синтаксисом,
> > > аналогичным git-push(1)?
> > 
> > Я попробую сделать.
> 
> А стоит ли?  Может быть есть другие точки зрения на вопрос?

Всех устраивает или всем всё равно?


-- 
ldv

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

Re: [devel] Q: gear-push-build

[Alexey Tourbin]

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

On Wed, Nov 15, 2006 at 12:04:47AM +0300, Dmitry V. Levin wrote:
> > > > Не будет ли тогда проще какой-нибудь gear-push-build с синтаксисом,
> > > > аналогичным git-push(1)?
> > > 
> > > Я попробую сделать.
> > 
> > А стоит ли?  Может быть есть другие точки зрения на вопрос?
> Всех устраивает или всем всё равно?

Никто не врубается. :)

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

Re: [devel] Q: gear-push-build

[Anton Farygin]

Alexey Tourbin wrote:
> On Wed, Nov 15, 2006 at 12:04:47AM +0300, Dmitry V. Levin wrote:
>>>>> Не будет ли тогда проще какой-нибудь gear-push-build с синтаксисом,
>>>>> аналогичным git-push(1)?
>>>> Я попробую сделать.
>>> А стоит ли?  Может быть есть другие точки зрения на вопрос?
>> Всех устраивает или всем всё равно?
> 
> Никто не врубается. :)

+1

Вы разговариваете на непонятном нам языке ;)

Rgds,
Rider

Re: [devel] Q: gear-push-build

[Aleksey Avdeev]

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

Dmitry V. Levin пишет:
> On Sat, Nov 11, 2006 at 12:07:35AM +0300, Dmitry V. Levin wrote:
> 
>>On Fri, Nov 10, 2006 at 11:57:28PM +0300, Alexey Gladkov wrote:
>>
>>>Dmitry V. Levin пишет:
>>>
>>>>В таком ракурсе я не вполне уверен, что release tag будет наиболее удобным
>>>>способом инициировать процесс сборки.
>>>>
>>>>Не будет ли тогда проще какой-нибудь gear-push-build с синтаксисом,
>>>>аналогичным git-push(1)?
>>>
>>>Я попробую сделать.
>>
>>А стоит ли?  Может быть есть другие точки зрения на вопрос?
> 
> 
> Всех устраивает или всем всё равно?

  Git ещё не настолько очевиден для меня, чтобы высказываться по данной
теме (результаты мысленного и реального экспериментов расходятся
достаточно часто).

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 550 bytes --]

Re: [devel] Q: gear-push-build

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [061115 00:05]:
> > > > Не будет ли тогда проще какой-нибудь gear-push-build с синтаксисом,
> > > > аналогичным git-push(1)?
> > > Я попробую сделать.
> > А стоит ли?  Может быть есть другие точки зрения на вопрос?
> Всех устраивает или всем всё равно?
Мне бы хотелось видеть, куда показывает тег последней
отправленной сборки.  Может ввести возможность создания тегов
вида refs/releases/<release-tag>-<name> ?  С дублированием name в
содержимом тега и возможно именем нужного rule-файла.

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] Q: gear-push-build

[Dmitry V. Levin]

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

On Wed, Nov 15, 2006 at 01:18:56AM +0300, Alexey Tourbin wrote:
> On Wed, Nov 15, 2006 at 12:04:47AM +0300, Dmitry V. Levin wrote:
> > > > > Не будет ли тогда проще какой-нибудь gear-push-build с синтаксисом,
> > > > > аналогичным git-push(1)?
> > > > 
> > > > Я попробую сделать.
> > > 
> > > А стоит ли?  Может быть есть другие точки зрения на вопрос?
> > Всех устраивает или всем всё равно?
> 
> Никто не врубается. :)

Речь идёт о том, каким образом мантейнер пакета будет инициировать сборку
(например, в Sisyphus) из своего gear-репозитория пакета на git.alt.

Обсуждаются два варианта:
1. Посредством git-push'а т.н. release-тэгов
  refs/releases/имя-репозитория,
  или как мне недавно пришло в голову,
  refs/releases/имя-репозитория/имя-пакета.
2. Посредством утилиты с неустоявшимся именем с синтаксисом, аналогичным
  git-push(1), которая будет выполнять
  ssh git.alt операция-с-неустоявшимся-именем,
  которая будет делать примерно то же, что и hooks/update при обработке
  release-тэгов.

Первый вариант принципиально отличается от второго тем, что информация,
необходимая для инициации сборки пакета, будет храниться в репозитории,
в котором находится исходный код, со всеми + и - такого подхода.


-- 
ldv

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

Re: [devel] Q: gear-push-build

[Kirill Maslinsky]

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

> Речь идёт о том, каким образом мантейнер пакета будет инициировать сборку
> (например, в Sisyphus) из своего gear-репозитория пакета на git.alt.
> 
> Обсуждаются два варианта:
> 1. Посредством git-push'а т.н. release-тэгов
>   refs/releases/имя-репозитория,
>   или как мне недавно пришло в голову,
>   refs/releases/имя-репозитория/имя-пакета.
> 2. Посредством утилиты с неустоявшимся именем с синтаксисом, аналогичным
>   git-push(1), которая будет выполнять
>   ssh git.alt операция-с-неустоявшимся-именем,
>   которая будет делать примерно то же, что и hooks/update при обработке
>   release-тэгов.
> 
> Первый вариант принципиально отличается от второго тем, что информация,
> необходимая для инициации сборки пакета, будет храниться в репозитории,
> в котором находится исходный код, со всеми + и - такого подхода.

Все-таки не до конца понятно: можно ли перечислить, что входит 
в "информацию, необходимую для _инициации_ сборки"?
Правильно ли я понимаю, что это не то же самое, что 
"информация, необходимая для _сборки_" ?

Из общих соображений: в репозитории определенно должно храниться
достаточно информации для сопоставления результата сборки 
(конкретного бинарного пакета) и объекта в репозитории, из которого 
была произведена сборка. А инициировать процедуру сборки вроде 
как логичнее командой на git.alt.

Кстати, вопрос не по теме: а вообще в новой схеме устройства Сизифа
предусмотрен способ выяснить состав _сборочной среды_, в которой 
был собран конкретный бинарный пакет? 

Здесь же кроется вопрос о публикации srpm'ов -- ведь все равно же из них
должна строиться сборочная среда при обработке release-тега? 

-- 
Kirill Maslinsky
ALT Linux Documentation Team
http://heap.altlinux.ru

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

Re: [devel] Q: gear-push-build

[Dmitry V. Levin]

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

On Thu, Nov 16, 2006 at 11:44:19PM +0300, Kirill Maslinsky wrote:
> > Речь идёт о том, каким образом мантейнер пакета будет инициировать сборку
> > (например, в Sisyphus) из своего gear-репозитория пакета на git.alt.
> > 
> > Обсуждаются два варианта:
> > 1. Посредством git-push'а т.н. release-тэгов
> >   refs/releases/имя-репозитория,
> >   или как мне недавно пришло в голову,
> >   refs/releases/имя-репозитория/имя-пакета.
> > 2. Посредством утилиты с неустоявшимся именем с синтаксисом, аналогичным
> >   git-push(1), которая будет выполнять
> >   ssh git.alt операция-с-неустоявшимся-именем,
> >   которая будет делать примерно то же, что и hooks/update при обработке
> >   release-тэгов.
> > 
> > Первый вариант принципиально отличается от второго тем, что информация,
> > необходимая для инициации сборки пакета, будет храниться в репозитории,
> > в котором находится исходный код, со всеми + и - такого подхода.
> 
> Все-таки не до конца понятно: можно ли перечислить, что входит 
> в "информацию, необходимую для _инициации_ сборки"?

Перечисляю информацию, которая необходима для инициации сборки:
- имя репозитория, для которого инициируется сборка (напр., Sisyphus);
- url gear-репозитория, из которого инициируется сборка (напр.,
  /people/vsu/packages/kernel-image-2.6.18.git);
- имя подписанного тэга, по которому инициируется сборка (напр.,
  refs/tags/kernel-image-std-smp/2.6.18-alt1);
- имя исходного пакета, который должен получиться в результате сборки
  (напр., kernel-image-std-smp), требуется для проверки прав доступа.

> Правильно ли я понимаю, что это не то же самое, что 
> "информация, необходимая для _сборки_" ?

Это уже казуистика.  Для сборки нужно много чего ещё, например,
репозиторий с бинарными пакетами.

> Из общих соображений: в репозитории определенно должно храниться
> достаточно информации для сопоставления результата сборки 
> (конкретного бинарного пакета) и объекта в репозитории, из которого 
> была произведена сборка.

Например?

> А инициировать процедуру сборки вроде как логичнее командой на git.alt.

Может быть, я пока спрашиваю а не утверждаю.

> Кстати, вопрос не по теме: а вообще в новой схеме устройства Сизифа
> предусмотрен способ выяснить состав _сборочной среды_, в которой 
> был собран конкретный бинарный пакет? 

А что такое состав сборочной среды?  Является ли список установленных
пакетов достаточным?  А если к каждому из этих пакетов добавить его
SHA1HEADER?  А если добавить `uname -r`?  А если добавить ...?
На чём можно остановиться?
А может для характеристики сборочной среды достаточно sha1sum от того, на
чём мы в результате остановимся?  Это зависит от последующего применения.

> Здесь же кроется вопрос о публикации srpm'ов -- ведь все равно же из них
> должна строиться сборочная среда при обработке release-тега? 

Не понял вопрос.


-- 
ldv

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

Re: [devel] Q: gear-push-build

[Alexey Tourbin]

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

On Thu, Nov 16, 2006 at 10:11:43PM +0300, Dmitry V. Levin wrote:
> > > > А стоит ли?  Может быть есть другие точки зрения на вопрос?
> > > Всех устраивает или всем всё равно?
> > 
> > Никто не врубается. :)
> 
> Речь идёт о том, каким образом мантейнер пакета будет инициировать сборку
> (например, в Sisyphus) из своего gear-репозитория пакета на git.alt.

Это понятно.  Непонятны тонкости.

> Обсуждаются два варианта:
> 1. Посредством git-push'а т.н. release-тэгов
>   refs/releases/имя-репозитория,
>   или как мне недавно пришло в голову,
>   refs/releases/имя-репозитория/имя-пакета.
> 2. Посредством утилиты с неустоявшимся именем с синтаксисом, аналогичным
>   git-push(1), которая будет выполнять
>   ssh git.alt операция-с-неустоявшимся-именем,
>   которая будет делать примерно то же, что и hooks/update при обработке
>   release-тэгов.
> 
> Первый вариант принципиально отличается от второго тем, что информация,
> необходимая для инициации сборки пакета, будет храниться в репозитории,
> в котором находится исходный код, со всеми + и - такого подхода.

Я всегда думал над первым вариантом.  Т.е. прошел таг *-alt* -- пакет
пошел на сборку.

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

Re: [devel] Q: gear-push-build

[Alexey Tourbin]

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

On Thu, Nov 16, 2006 at 11:44:19PM +0300, Kirill Maslinsky wrote:
> Кстати, вопрос не по теме: а вообще в новой схеме устройства Сизифа
> предусмотрен способ выяснить состав _сборочной среды_, в которой 
> был собран конкретный бинарный пакет? 

А фазу луны, при которой был собран пакет, ты не хочешь выяснить?
По-моему достаточно сохранить build log, в который можно посмотреть.

> Здесь же кроется вопрос о публикации srpm'ов -- ведь все равно же из них
> должна строиться сборочная среда при обработке release-тега? 

Сборочная среда не строится из srpm'ов.

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

Re: [devel] Q: gear-push-build

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [061116 22:11]:
> Обсуждаются два варианта:
> 1. Посредством git-push'а т.н. release-тэгов
>   refs/releases/имя-репозитория,
>   или как мне недавно пришло в голову,
>   refs/releases/имя-репозитория/имя-пакета.
А что будет с существующими refs/releases/имя-репозитория ?
Нормально заоверрайдится?

> 2. Посредством утилиты с неустоявшимся именем с синтаксисом, аналогичным

> Первый вариант принципиально отличается от второго тем, что информация,
> необходимая для инициации сборки пакета, будет храниться в репозитории,
> в котором находится исходный код, со всеми + и - такого подхода.
Нужны оба варианта.  Первый отвечает на вопрос "что собирать", а
второй на вопрос "когда и в каком порядке это собирать".  Я себе
представляю это примерно так:

$ gear-release -n xxx-aaa --rules .gear-rules-aaa sisyphus
$ gear-release -n xxx-bbb --rules .gear-rules-bbb sisyphus
$ git-push -a

[прошло некоторое время]

$ gear-push-build --begin sisyphus
$ gear-push-build xxx-tools
$ gear-push-build --name xxx-aaa xxx
$ gear-push-build xxx-plugins-aaa
$ gear-push-build --name xxx-bbb xxx
$ gear-push-build xxx-plugins-bbb
$ gear-push-build --commit sisyphus

И пакеты будут собираться в таком порядке в одну транзакцию:

xxx-tools
xxx-aaa (из репозитария xxx)
xxx-plugins-aaa
xxx-bbb (из репозитария xxx)
xxx-plugins-bbb

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] Q: gear-push-build

[Stanislav Ievlev]

Кстати о push-build .
Вспомнилось тут, что станет обязательным требование прописывать тег Packager.

Вопрос: А можно избежать этого? Ведь эту информацию всегда можно
подчепнуть из переменных которыми пользуется git, когда пишет сообщения в
commit. Кажется git даже работать-то отказывается , если не может узнать
имя запаковщика, остаётся только добавить проверку на соответствие этого
имени нашим правилам.

Re: [devel] Q: gear-push-build

[Alexey Gladkov]

Alexey I. Froloff пишет:

Ты не понял. Это два принципиально разных подхода.

> А что будет с существующими refs/releases/имя-репозитория ?
> Нормально заоверрайдится?

Старая схема с релиз-тэгами будет полностью упразднена.

> Нужны оба варианта.  Первый отвечает на вопрос "что собирать", а
> второй на вопрос "когда и в каком порядке это собирать".  Я себе
> представляю это примерно так:

По новой схеме ты работаешь с репозиторием пакета, делаешь какие
угодно тэги и/или бранчи и push'ишь это на giter сервер. Когда пакет
готов публикации ставишь и push'ишь тэг версии. После того как
репозиторий готов, делаешь gear-push-build <branch> (branch - это то
что ты назвал "имя-репозитория" в refs/releases/имя-репозитория) ...
после этой команды этот репозиторий встаёт в очередь на сборку.

Транзакций при обработке очереди не предусматривается. Поэтому все
пакеты, отправленные в очередь, будут "видеть" друг друга. Таким
образом порядок выполнения тобой команд gear-push-build будет
определять порядок сборки.

Как видишь, релиз-тэг не нужен вообще. Ты сам говоришь giter серверу
когда и для какого бранча нужно собрать пакет из конкретного репозитория.

-- 
Rgrds, legion

Re: [devel] Q: gear-push-build

[Alexey I. Froloff]

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

* Alexey Gladkov <legion@> [061121 13:01]:
> Транзакций при обработке очереди не предусматривается. Поэтому все
> пакеты, отправленные в очередь, будут "видеть" друг друга. Таким
> образом порядок выполнения тобой команд gear-push-build будет
> определять порядок сборки.
А можно это как-то поподробней описать?  Я при такой формулировке
вижу один вариант:

Мантейнер отправляет пакеты на сборку, на сервере они
складываются в очередь.  В один прекрасный момент N пакетов из
очереди (N может быть 1 или sizeof(очередь)) поочерёдно
собираются в одном хашере с уникальным для каждого мантейнера
--repo.  В какой-то момент этот repo мержится в сизиф и
обнуляется.  Условие сидимости сохраняется

При таком подходе есть несколько недостатков (в засисимости от
реализации):

1. Нельзя сказать когда начинать сборку.  Например, я хочу
собрать N пакетов, но сборка стартовала после заливки M пакетов
(не применимо если сборка начинается сразу после "заливки"
пакета).  Теоретически, тут ничего не ломается, но придётся ждать
следующего разбора очереди.

2. Нельзя указать когда переносить все собранные пакеты в Сизиф.
Я заливаю пакеты libfoo и пересобранные с ним bar и baz.
Единственный случай несоздания unmet'ов - перенос всех трёх
пересобраных пакетов.

3. Если перенос пакетов в Сизиф наступает только после того как
очередь полностью будет разобрана - есть шанс устроить "запор"
большими пакетами.


Ещё вопрос - будут ли эти личные repo (тот самый персональный
Daedalus) доступны простым смертным?  Необходимость этого зависит
от способов разбора очереди и слияния repo с Сизифом.


И главное - как будут обрабатываться ошибки?  Например неудачная
сборка libfoo - что будет с bar и baz?  Я не хочу писать жёсткие
buildrequires :-/

-- 
Regards,
Sir Raorn.

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

Re: [devel] Q: gear-push-build

[Dmitry V. Levin]

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

On Mon, Nov 27, 2006 at 12:07:04AM +0300, Alexey I. Froloff wrote:
> * Alexey Gladkov <legion@> [061121 13:01]:
> > Транзакций при обработке очереди не предусматривается. Поэтому все
> > пакеты, отправленные в очередь, будут "видеть" друг друга. Таким
> > образом порядок выполнения тобой команд gear-push-build будет
> > определять порядок сборки.
> А можно это как-то поподробней описать?

Кстати да.  Ведь Legion очень любит сначала закодить, а всё остальное
потом, в то время как лучше сперва специфицировать, а потом кодить.


-- 
ldv

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

Re: [devel] Q: gear-push-build

[Alexey Gladkov]

Dmitry V. Levin пишет:
> Кстати да.  Ведь Legion очень любит сначала закодить, а всё остальное
> потом, в то время как лучше сперва специфицировать, а потом кодить.

Когда нет времи на проектирование, то это единственный способ. Все же
очень хотят уже фриз делать по новой схеме ... что же мне остаётся
делать ?!

"Hу, даёшь, ядрёна вошь! И олень тебе не гож? А вчерась мытарил душу:
вынь оленя да положь!" (с) Леонид Филатов "ПРО ФЕДОТА-СТРЕЛЬЦА,
УДАЛОГО МОЛОДЦА"

-- 
Rgrds, legion

Re: [devel] Q: gear-push-build

[Alexey Gladkov]

Alexey I. Froloff пишет:
> Мантейнер отправляет пакеты на сборку, на сервере они
> складываются в очередь.  В один прекрасный момент N пакетов из
> очереди (N может быть 1 или sizeof(очередь)) поочерёдно
> собираются в одном хашере с уникальным для каждого мантейнера
> --repo.  В какой-то момент этот repo мержится в сизиф и
> обнуляется.  Условие сидимости сохраняется

Почти так. Пакеты собираются один за другим и после успешной сборки
сразу публикуются. Группировки по пользователю не будет. Следующий
пакет будет собираться на общем результате. Никаких кэшей не будет.
Unmets проверяться не будут.

Мантейнер какого-нибудь пакета системного уровня и так может устроить
любую провокацию и проверка на unmets тут совершенно не поможет.

> 1. Нельзя сказать когда начинать сборку.  Например, я хочу
> собрать N пакетов, но сборка стартовала после заливки M пакетов
> (не применимо если сборка начинается сразу после "заливки"
> пакета).  Теоретически, тут ничего не ломается, но придётся ждать
> следующего разбора очереди.

Если результат очереди сразу публикуется, то когда начать сборку
совершенно понятно. Пакеты будут собираться по мере их поступления.

> 2. Нельзя указать когда переносить все собранные пакеты в Сизиф.
> Я заливаю пакеты libfoo и пересобранные с ним bar и baz.
> Единственный случай несоздания unmet'ов - перенос всех трёх
> пересобраных пакетов.

Тут тоже понятно. Если все они собирутся, то неудовлетворённостей не
будет. В промежутке между сборками libfoo и  bar/baz они конечно будут.

> 3. Если перенос пакетов в Сизиф наступает только после того как
> очередь полностью будет разобрана - есть шанс устроить "запор"
> большими пакетами.

Именно пакеты собираются без буферизации и группировки.

> Ещё вопрос - будут ли эти личные repo (тот самый персональный
> Daedalus) доступны простым смертным?  Необходимость этого зависит
> от способов разбора очереди и слияния repo с Сизифом.

Не будет.

> И главное - как будут обрабатываться ошибки?  Например неудачная
> сборка libfoo - что будет с bar и baz?  Я не хочу писать жёсткие
> buildrequires :-/

Они собируться со старыми версиями если это возможно. Собственно как и
сейчас. Строгость или мягкость сборочных зависимостей это личное
решение каждого мантейнера. Демократия.

-- 
Rgrds, legion

Re: [devel] Q: gear-push-build

[Alexey I. Froloff]

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

* Alexey Gladkov <legion@> [061127 11:03]:
> Если результат очереди сразу публикуется, то когда начать сборку
> совершенно понятно. Пакеты будут собираться по мере их поступления.
Т.е. пока пересобирается какой-ньдь OOo, все курят бамбук?
Никакого распаралеливания, всё в одном хашере?

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] Q: gear-push-build

[Alexey Gladkov]

Alexey I. Froloff пишет:
> Т.е. пока пересобирается какой-ньдь OOo, все курят бамбук?
> Никакого распаралеливания, всё в одном хашере?

Да. Если ты придумаешь ещё несколько примеров с другими большими
пакетами, то эта идя не покажется тебе настолько абсурдной какой ты её
хотел показать. :)

-- 
Rgrds, legion

Re: [devel] ooo-2.0.4-alt2

[Dmitry V. Levin]

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

On Mon, Nov 27, 2006 at 11:11:18AM +0300, Alexey I. Froloff wrote:
> * Alexey Gladkov <legion@> [061127 11:03]:
> > Если результат очереди сразу публикуется, то когда начать сборку
> > совершенно понятно. Пакеты будут собираться по мере их поступления.
> Т.е. пока пересобирается какой-ньдь OOo, все курят бамбук?

Кстати говоря, ooo-2.0.4-alt2 собрался за 4 часа 50 минут.
Это самый долгособирающийся пакет.

> Никакого распаралеливания, всё в одном хашере?

Распараллеливание по архитектурам будет, остальное обсуждаемо.


-- 
ldv

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