[devel] sandman на cvs.altlinux.org

[devel] sandman на cvs.altlinux.org

[Anton Farygin]

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

Всем привет.

Господа, вопрос стоит в поднятии sandman на cvs.altlinux.org для 
хранения развернутого дерева репозитария.

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

Соответственно вопрос к Диме: когда планируется поднимать sandman на 
cvs.altlinux.org ?

И как в этом случае будет жить hasher? Где будет происходить сборка ?

Rgds,
Rider

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

Re: [devel] sandman на cvs.altlinux.org

[Dmitry V. Levin]

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

Greetings!

On Mon, Aug 04, 2003 at 12:36:16PM +0400, Anton Farygin wrote:
> Всем привет.
> 
> Господа, вопрос стоит в поднятии sandman на cvs.altlinux.org для 
> хранения развернутого дерева репозитария.
> 
> Саша Боковой утверждает что он договорился об этом с Димой Левиным.

Он договорился о хранении развернутого дерева репозитария, а также о
структуре этого репозитория (хотя детали последнего стоит уточнить,
ибо я их начал забывать).

О том, что эту задачу будет решать sandman, договорённости не было,
хотя возможность этого технически не исключена.

> Соответственно вопрос к Диме: когда планируется поднимать sandman на 
> cvs.altlinux.org ?

Это зависит от ответа на предыдущий вопрос.

> И как в этом случае будет жить hasher? Где будет происходить сборка ?

Общего сборочного сервера "for everyone" не планируется, по крайней мере,
до тех пор, пока кто-нибудь не проспонсирует такой сервер.

hasher будет жить у каждого packager'а как средство проверки собираемости
пакетов (напр. в среде Сизифа).

hasher обрабатывает /incoming/.


--
ldv

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

Re: [devel] sandman на cvs.altlinux.org

[Anton Farygin]

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

Dmitry V. Levin пишет:
> Greetings!
> 
> On Mon, Aug 04, 2003 at 12:36:16PM +0400, Anton Farygin wrote:
> 
>>Всем привет.
>>
>>Господа, вопрос стоит в поднятии sandman на cvs.altlinux.org для 
>>хранения развернутого дерева репозитария.
>>
>>Саша Боковой утверждает что он договорился об этом с Димой Левиным.
> 
> 
> Он договорился о хранении развернутого дерева репозитария, а также о
> структуре этого репозитория (хотя детали последнего стоит уточнить,
> ибо я их начал забывать).
> 
> О том, что эту задачу будет решать sandman, договорённости не было,
> хотя возможность этого технически не исключена.

Тогда может быть стоит поднять на cvs.altlinux.org sandman и начать им 
пользоваться для _хранения_ ?

Что для этого нужно?

> 
> 
>>Соответственно вопрос к Диме: когда планируется поднимать sandman на 
>>cvs.altlinux.org ?
> 
> 
> Это зависит от ответа на предыдущий вопрос.
> 
> 
>>И как в этом случае будет жить hasher? Где будет происходить сборка ?
> 
> 
> Общего сборочного сервера "for everyone" не планируется, по крайней мере,
> до тех пор, пока кто-нибудь не проспонсирует такой сервер.

Ну это решаемо - большинство задач наши сборочные сервера ночью потянут 
и за ночь по идее смогут разгрести среднего размера incoming.

2ab: sandman поддерживает отложенные на время сборки ?
А зависшие процессы прибивать сможет ?
Сможет ли он разбрасывать задачи между сборочными серверами _своими_ 
силами, без distcc ?

насколько трудоемко будет его научить использовать другое средство для 
сборки пакетов, например hasher ?

> 
> hasher будет жить у каждого packager'а как средство проверки собираемости
> пакетов (напр. в среде Сизифа).
> 
> hasher обрабатывает /incoming/.

Rgds,
Rider

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

Re: [devel] sandman на cvs.altlinux.org

[Dmitry V. Levin]

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

On Mon, Aug 04, 2003 at 12:51:22PM +0400, Anton Farygin wrote:
> >>Господа, вопрос стоит в поднятии sandman на cvs.altlinux.org для 
> >>хранения развернутого дерева репозитария.
> >>
> >>Саша Боковой утверждает что он договорился об этом с Димой Левиным.
> >
> >
> >Он договорился о хранении развернутого дерева репозитария, а также о
> >структуре этого репозитория (хотя детали последнего стоит уточнить,
> >ибо я их начал забывать).
> >
> >О том, что эту задачу будет решать sandman, договорённости не было,
> >хотя возможность этого технически не исключена.
> 
> Тогда может быть стоит поднять на cvs.altlinux.org sandman и начать им 
> пользоваться для _хранения_ ?
> 
> Что для этого нужно?

1. Уточнить планируемую структуру репозитария, который, напоминаю, будет
   readonly (пока не придумаем распределённый репозитарий).

2. Определить, какие ресурсы требуются для работы sandman'а в режиме
   поддержания такого репозитария.

3. Установить sandman или другое средство поддержания репозитария.

> >>И как в этом случае будет жить hasher? Где будет происходить сборка ?
> >
> >Общего сборочного сервера "for everyone" не планируется, по крайней мере,
> >до тех пор, пока кто-нибудь не проспонсирует такой сервер.
> 
> Ну это решаемо - большинство задач наши сборочные сервера ночью потянут 
> и за ночь по идее смогут разгрести среднего размера incoming.

А где тогда организовать циклическую пересборку Сизифа?


--
ldv

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

Re: [devel] sandman на cvs.altlinux.org

[Anton Farygin]

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

Dmitry V. Levin пишет:
> On Mon, Aug 04, 2003 at 12:51:22PM +0400, Anton Farygin wrote:
> 
>>>>Господа, вопрос стоит в поднятии sandman на cvs.altlinux.org для 
>>>>хранения развернутого дерева репозитария.
>>>>
>>>>Саша Боковой утверждает что он договорился об этом с Димой Левиным.
>>>
>>>
>>>Он договорился о хранении развернутого дерева репозитария, а также о
>>>структуре этого репозитория (хотя детали последнего стоит уточнить,
>>>ибо я их начал забывать).
>>>
>>>О том, что эту задачу будет решать sandman, договорённости не было,
>>>хотя возможность этого технически не исключена.
>>
>>Тогда может быть стоит поднять на cvs.altlinux.org sandman и начать им 
>>пользоваться для _хранения_ ?
>>
>>Что для этого нужно?
> 
> 
> 1. Уточнить планируемую структуру репозитария, который, напоминаю, будет
>    readonly (пока не придумаем распределённый репозитарий).

Упс... а зачем нам нужен readonly репозитарий ? Толку то от него ?

> 
> 2. Определить, какие ресурсы требуются для работы sandman'а в режиме
>    поддержания такого репозитария.

2ab

> 
> 3. Установить sandman или другое средство поддержания репозитария.

ok. После решения двух первых пунктов.

> 
> 
>>>>И как в этом случае будет жить hasher? Где будет происходить сборка ?
>>>
>>>Общего сборочного сервера "for everyone" не планируется, по крайней мере,
>>>до тех пор, пока кто-нибудь не проспонсирует такой сервер.
>>
>>Ну это решаемо - большинство задач наши сборочные сервера ночью потянут 
>>и за ночь по идее смогут разгрести среднего размера incoming.
> 
> 
> А где тогда организовать циклическую пересборку Сизифа?

Для циклической пересборки выделить один сервер. Остальные четыре - 
можно для разбора incoming.

В любом случае пяти сборочных серверов должно хватить.

Rgds,
Rider

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

Re: [devel] sandman на cvs.altlinux.org

[Dmitry V. Levin]

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

On Mon, Aug 04, 2003 at 01:03:57PM +0400, Anton Farygin wrote:
> >1. Уточнить планируемую структуру репозитария, который, напоминаю, будет
> >   readonly (пока не придумаем распределённый репозитарий).
> 
> Упс... а зачем нам нужен readonly репозитарий ? Толку то от него ?

Чтобы каждый мог сделать checkout/update/diff с минимальными затратами на
трафик.

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

> >>>>И как в этом случае будет жить hasher? Где будет происходить сборка ?
> >>>
> >>>Общего сборочного сервера "for everyone" не планируется, по крайней мере,
> >>>до тех пор, пока кто-нибудь не проспонсирует такой сервер.
> >>
> >>Ну это решаемо - большинство задач наши сборочные сервера ночью потянут 
> >>и за ночь по идее смогут разгрести среднего размера incoming.
> >
> >
> >А где тогда организовать циклическую пересборку Сизифа?
> 
> Для циклической пересборки выделить один сервер. Остальные четыре - 
> можно для разбора incoming.
> 
> В любом случае пяти сборочных серверов должно хватить.

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


--
ldv

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

Re: [devel] sandman на cvs.altlinux.org

[Anton Farygin]

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

Dmitry V. Levin пишет:
> On Mon, Aug 04, 2003 at 01:03:57PM +0400, Anton Farygin wrote:
> 
>>>1. Уточнить планируемую структуру репозитария, который, напоминаю, будет
>>>  readonly (пока не придумаем распределённый репозитарий).
>>
>>Упс... а зачем нам нужен readonly репозитарий ? Толку то от него ?
> 
> 
> Чтобы каждый мог сделать checkout/update/diff с минимальными затратами на
> трафик.
> 
> Для того, чтобы сделать rw, нужен распределённый репозитарий, о котором
> сейчас речь не идёт, ибо он даже не разработан.
> 
> 
>>>>>>И как в этом случае будет жить hasher? Где будет происходить сборка ?
>>>>>
>>>>>Общего сборочного сервера "for everyone" не планируется, по крайней мере,
>>>>>до тех пор, пока кто-нибудь не проспонсирует такой сервер.
>>>>
>>>>Ну это решаемо - большинство задач наши сборочные сервера ночью потянут 
>>>>и за ночь по идее смогут разгрести среднего размера incoming.
>>>
>>>
>>>А где тогда организовать циклическую пересборку Сизифа?
>>
>>Для циклической пересборки выделить один сервер. Остальные четыре - 
>>можно для разбора incoming.
>>
>>В любом случае пяти сборочных серверов должно хватить.
> 
> 
> Перечисли раскладку предполагаемой загрузку, чтобы было понятно, на чем
> основано твоё предложение.

mash - циклическая пересборка Sisyphus хешером. За ночь собирается 
примерно 30%.
skif, altair, basalt, netgate - разбор incoming (тоже ночью).

В случае, когда нам нужно ускорить пересборку Sisyphus - мы можем снять 
один из четырех incoming серверов на Sisyphus.
Остается только решить вопрос с пробросом заданий между серверами.

Rgds,
Rider

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

Re: [devel] sandman на cvs.altlinux.org

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@altlinux.org> [030804 12:59]:
> hasher будет жить у каждого packager'а как средство проверки
> собираемости пакетов (напр. в среде Сизифа).
Именно hasher или можно пользоваться sandman'ом?

P.S. Я специально уточняю это вопрос в рассылке...

-- 
Regards, Sir Raorn.
-------------------
alsa не будет исправлена. Считайте что она unsupported до момента выхода
любой стабильной версии.
		-- rider in devel@

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

Re: [devel] sandman на cvs.altlinux.org

[Alexander Bokovoy]

On Mon, Aug 04, 2003 at 01:08:59PM +0400, Dmitry V. Levin wrote:
> On Mon, Aug 04, 2003 at 01:03:57PM +0400, Anton Farygin wrote:
> > >1. Уточнить планируемую структуру репозитария, который, напоминаю, будет
> > >   readonly (пока не придумаем распределённый репозитарий).
> > 
> > Упс... а зачем нам нужен readonly репозитарий ? Толку то от него ?
> 
> Чтобы каждый мог сделать checkout/update/diff с минимальными затратами на
> трафик.
> 
> Для того, чтобы сделать rw, нужен распределённый репозитарий, о котором
> сейчас речь не идёт, ибо он даже не разработан.
Господа, я напишу вечером подробности о своем видении того, что
предлагается и как в эту схему вписывается использование sandman в
read-only режиме. Писал, писал, написал большое письмо и оно мистически
пропало вместе с процессом vim-а, в котором это происходило. Даже в TMPDIR
не осталось следов. :(

-- 
/ Alexander Bokovoy
---
I want you to MEMORIZE the collected poems of EDNA ST VINCENT MILLAY
... BACKWARDS!!

Re: [devel] sandman на cvs.altlinux.org

[Dmitry V. Levin]

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

On Mon, Aug 04, 2003 at 01:29:07PM +0400, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@altlinux.org> [030804 12:59]:
> > hasher будет жить у каждого packager'а как средство проверки
> > собираемости пакетов (напр. в среде Сизифа).
> Именно hasher или можно пользоваться sandman'ом?
> 
> P.S. Я специально уточняю это вопрос в рассылке...

На данный момент и до тех пор, пока не будет заявлено о другой схеме,
можно пользоваться чем угодно, лишь бы в hasher'е была гарантирована
собираемость.  При этом желательно использовать contents_index.


--
ldv

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

Re: [devel] sandman на cvs.altlinux.org

[Anton Farygin]

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

Dmitry V. Levin пишет:
> On Mon, Aug 04, 2003 at 01:29:07PM +0400, Alexey I. Froloff wrote:
> 
>>* Dmitry V. Levin <ldv@altlinux.org> [030804 12:59]:
>>
>>>hasher будет жить у каждого packager'а как средство проверки
>>>собираемости пакетов (напр. в среде Сизифа).
>>
>>Именно hasher или можно пользоваться sandman'ом?
>>
>>P.S. Я специально уточняю это вопрос в рассылке...
> 
> 
> На данный момент и до тех пор, пока не будет заявлено о другой схеме,
> можно пользоваться чем угодно, лишь бы в hasher'е была гарантирована
> собираемость.  При этом желательно использовать contents_index.

Перевожу:

т.е. один черт гарантировать собираемость в hasher может только тест 
сборки в hasher, то на данный момент можно пользоваться только им, и 
ничем другим. ;-)

Rgds,
Rider

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

Re: [devel] sandman на cvs.altlinux.org

[Victor V Ismakaev]

4 Август 2003 16:12, Dmitry V. Levin написал:
> On Mon, Aug 04, 2003 at 01:29:07PM +0400, Alexey I. Froloff wrote:
> > * Dmitry V. Levin <ldv@altlinux.org> [030804 12:59]:
> > > hasher будет жить у каждого packager'а как средство проверки
> > > собираемости пакетов (напр. в среде Сизифа).
> >
> > Именно hasher или можно пользоваться sandman'ом?
> >
> > P.S. Я специально уточняю это вопрос в рассылке...
>
> На данный момент и до тех пор, пока не будет заявлено о другой схеме,
> можно пользоваться чем угодно, лишь бы в hasher'е была гарантирована
> собираемость.  При этом желательно использовать contents_index.
А в /etc/hasher-priv/user.d/$USER его можно как-то прописать?
Или только в ком строке задавать?

-- 
С уважением
Виктор В Исмакаев
ivv@altlinux.ru

Re: [devel] sandman на cvs.altlinux.org

[Dmitry V. Levin]

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

On Mon, Aug 04, 2003 at 02:18:02PM +0400, Anton Farygin wrote:
> >>>hasher будет жить у каждого packager'а как средство проверки
> >>>собираемости пакетов (напр. в среде Сизифа).
> >>
> >>Именно hasher или можно пользоваться sandman'ом?
> >>
> >>P.S. Я специально уточняю это вопрос в рассылке...
> >
> >На данный момент и до тех пор, пока не будет заявлено о другой схеме,
> >можно пользоваться чем угодно, лишь бы в hasher'е была гарантирована
> >собираемость.  При этом желательно использовать contents_index.
> 
> Перевожу:
> 
> т.е. один черт гарантировать собираемость в hasher может только тест 
> сборки в hasher, то на данный момент можно пользоваться только им, и 
> ничем другим. ;-)

Это не так, ибо собираемость sandman'ом гарантирует собираемость hasher'ом
не менее чем на 90%.


--
ldv

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

Re: [devel] sandman на cvs.altlinux.org

[Sergey Bolshakov]

>>>>> "Dmitry" == Dmitry V Levin <ldv@altlinux.org> writes:
[skipped]
 >> Перевожу:
 >> 
 >> т.е. один черт гарантировать собираемость в hasher может только тест 
 >> сборки в hasher, то на данный момент можно пользоваться только им, и 
 >> ничем другим. ;-)

 > Это не так, ибо собираемость sandman'ом гарантирует собираемость hasher'ом
 > не менее чем на 90%.

И наоборот :)

-- 

Re: [devel] sandman на cvs.altlinux.org

[Dmitry V. Levin]

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

On Mon, Aug 04, 2003 at 04:22:10PM +0600, Victor V Ismakaev wrote:
> А в /etc/hasher-priv/user.d/$USER его можно как-то прописать?

Нет, ибо это к hasher-priv никакого отношения не имеет.

hasher-priv - это привилегированная часть hasher'а, которая отвечает за
создание файлов устройств и переключение между псевдопользователями.

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

> Или только в ком строке задавать?

Можно написать alias. :)


--
ldv

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

Re: [devel] sandman на cvs.altlinux.org

[Anton Farygin]

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

Sergey Bolshakov пишет:
>>>>>>"Dmitry" == Dmitry V Levin <ldv@altlinux.org> writes:
> 
> [skipped]
>  >> Перевожу:
>  >> 
>  >> т.е. один черт гарантировать собираемость в hasher может только тест 
>  >> сборки в hasher, то на данный момент можно пользоваться только им, и 
>  >> ничем другим. ;-)
> 
>  > Это не так, ибо собираемость sandman'ом гарантирует собираемость hasher'ом
>  > не менее чем на 90%.
> 
> И наоборот :)
> 

А как вы считали эти 90% ?

Rgds
Rider

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

Re: [devel] sandman на cvs.altlinux.org

[Victor V Ismakaev]

4 Август 2003 16:26, Dmitry V. Levin написал:
> On Mon, Aug 04, 2003 at 04:22:10PM +0600, Victor V Ismakaev wrote:
> > А в /etc/hasher-priv/user.d/$USER его можно как-то прописать?
>
> Нет, ибо это к hasher-priv никакого отношения не имеет.
>
> hasher-priv - это привилегированная часть hasher'а, которая отвечает за
> создание файлов устройств и переключение между псевдопользователями.
>
> Соответственно, у неё есть ряд полезных слабодокументированных свойств.
А почему бы их хорошо не задокументировать? :))
 Понимаю,что есть исходники - но человеку,не знающему С - это проблематично.

> > > > Или только в ком строке задавать?
>
> Можно написать alias. :)
Само-собой :)

-- 
С уважением
Виктор В Исмакаев
ivv@altlinux.ru

Re: [devel] sandman на cvs.altlinux.org

[Dmitry V. Levin]

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

On Mon, Aug 04, 2003 at 05:04:14PM +0600, Victor V Ismakaev wrote:
> > > А в /etc/hasher-priv/user.d/$USER его можно как-то прописать?
> >
> > Нет, ибо это к hasher-priv никакого отношения не имеет.
> >
> > hasher-priv - это привилегированная часть hasher'а, которая отвечает за
> > создание файлов устройств и переключение между псевдопользователями.
> >
> > Соответственно, у неё есть ряд полезных слабодокументированных свойств.
> А почему бы их хорошо не задокументировать? :))
>  Понимаю,что есть исходники - но человеку,не знающему С - это проблематично.

Для продвинутых пользователей есть /usr/share/doc/hasher-priv-0.3/DESIGN

Но это скорее control flow, а не readme.

> > > > > Или только в ком строке задавать?
> >
> > Можно написать alias. :)
> Само-собой :)

Ну вот и здорово. :)


--
ldv

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

Re: [devel] sandman на cvs.altlinux.org

[Alexander Bokovoy]

On Mon, Aug 04, 2003 at 12:50:35PM +0300, Alexander Bokovoy wrote:
> On Mon, Aug 04, 2003 at 01:08:59PM +0400, Dmitry V. Levin wrote:
> > On Mon, Aug 04, 2003 at 01:03:57PM +0400, Anton Farygin wrote:
> > > >1. Уточнить планируемую структуру репозитария, который, напоминаю, будет
> > > >   readonly (пока не придумаем распределённый репозитарий).
> > > 
> > > Упс... а зачем нам нужен readonly репозитарий ? Толку то от него ?
> > 
> > Чтобы каждый мог сделать checkout/update/diff с минимальными затратами на
> > трафик.
> > 
> > Для того, чтобы сделать rw, нужен распределённый репозитарий, о котором
> > сейчас речь не идёт, ибо он даже не разработан.
> Господа, я напишу вечером подробности о своем видении того, что
> предлагается и как в эту схему вписывается использование sandman в
> read-only режиме. Писал, писал, написал большое письмо и оно мистически
> пропало вместе с процессом vim-а, в котором это происходило. Даже в TMPDIR
> не осталось следов. :(
Итак, опус прикладывается:
=============================================================================

Одним из недостатков процесса разработки в рамках проекта ALT Linux
Team является отсутствие истории проекта, выражающееся в
невозможности отслеживания изменений в пакетах на протяжении их
эволюционирования, поскольку в любой момент времени доступен лишь
самый последний вариант каждого пакета в рамках ALT Linux Sisyphus и,
дискретно, версии, включаемые в выпускаемые дистрибутивы ALT Linux
Master, Junior, etc. К сожалению, такой подход ограничивает
возможности разработчиков по полноценному развитию проекта, поскольку
в таком случае каждый вынужден самостоятельно вести историю
необходимых ему (или поддерживаемых) пакетов, а также осложняет
разработку тех пакетов, которые поддерживаются распределенной группой
разработчиков.

Решением этой проблемы стало бы создание централизованного хранилища
всех версий пакетов, попадающих в ALT Linux Sisyphus как в основной
репозитарий. Такое централизованное хранилище могло бы служить
референтной базой данных всего проекта и в дальнейшем послужило бы
основой для распределенной системы разработки, отсутствие которой
ощущается все острее с ростом количества разработчиков и проектов,
выполняемых на пакетной базе ALT Linux Sisyphus.

Каковы же требования, предъявляемые к централизованному хранилищу?
Нам кажется, что таковыми могут быть следующие положения:

1) Возможность хранения версий исходных пакетов, как для исходных
   текстов, так и для spec-файлов.

2) Возможность автоматического обновления хранилища при изменении ALT
   Linux Sisyphus. На первом этапе это обновление должно быть
   единственным способом изменения хранилища, для всех остальных
   хранилище должно быть доступным только по чтению.

3) Возможность получения любой из хранящихся версий пакета с
   максимальным уровнем грануляции (пакет целиком, некоторый набор
   исходных файлов, spec-файл).

4) Контроль за зависимостями пакетов -- пакеты, которые невозможно
   пересобрать на текущей версии репозитария, в хранилище и в ALT
   Linux Sisyphus попадать не должны.

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

В связи с тем, что пакеты RPM представляют собой набор как текстовых,
так и бинарных объектов, то следует подробнее проработать схему
хранения пакетов. Существующие свободные системы SCM (software 
configuration management), к сожалению, не позволяют в достаточной
мере гибко хранить версии бинарных объектов, поэтому представляется
осмысленным использовать некоторую внешнию схему версионирования
бинарных объектов в пакетах RPM, управляемую посредством
контролируемых в SCM текстовых объектов пакета. Если обратиться к
содержимому любого исходного пакета RPM, то можно увидеть, что только
один текстовый объект в нем представляет достаточно информации для
контроля всех остальных -- текстовых и бинарных -- объектов пакета и
этим контролирующим объектом является spec-файл.

Spec-файл содержит исчерпывающую информацию, необходимую для контроля
пакета, включая его версию и подчиненные исходные файлы (исходники,
заплатки, конфигурационные файлы и т.д.). Благодаря наличию в пакете
RPM в ALT Linux режима предварительного анализа spec-файла (опция -bE
утилиты rpmbuild) возможна регуляризация spec-файла (раскрытие
макросов в именах файлов) с последующим вычленением составных
частей. Режим предварительного анализа также позволяет обнаружить
синтаксические ошибки в коде spec-файла и тем самым оградить хранилище
от заведомо неработоспособных сборок пакетов.

Таким образом, поместив spec-файл под контроль SCM с дополнительной
интеграцией имеющихся средств самого RPM, можно добиться четкого и
непротиворечивого управления содержимым исходного пакета. Какую же
структуру хранения можно использовать для этих целей?

В рамках проекта по построению сборочной и тестовой среды (BTE) нами
был создан механизм, позволяющий эффективно хранить и версионировать
пакеты. Этот механизм реализован в программе Sandman (пакеты sandman и
sandman-server). Sandman использует следующую структуру хранения:

1) Spec-файлы хранятся в CVS в отдельном модуле

2) Операции изменения spec-файла в CVS перехватываются и анализируются

3) По результатам анализа происходит версионирование и изменение
   исходных файлов пакета

4) Исходные файлы пакета хранятся в многоуровневой древовидной
   структуре, доступ к которой напрямую невозможен

Таким образом, существует единая точка входа в хранилище -- spec-файл
в CVS, через которую осуществляется изменение всего пакета. Каким же
образом хранятся остальные части пакета? Многоуровневая древовидная
структура представляет собой систему подкаталогов следующего вида:

уровень1   уровень2 уровень3 уровень4   уровень5
имя_пакета 
           serial
                    version
                             release
                                       исходники

Например, для пакета Ruby эта структура выглядит следующим образом:

/data/sandman/sisyphus/sources/ruby/
`--0
   |--1.6.6
   |  `--alt3
   |     |--rubyfaqall.html.bz2
   |     |--ruby-1.6.6.tar.bz2
   |     `--ProgrammingRuby-0.3a.tar.bz2
   |--1.6.7
   |  `--alt1
   |     |--ProgrammingRuby-0.3a.tar.bz2 -> ../../1.6.6/alt3/ProgrammingRuby-0.3a.tar.bz2
   |     |--rubyfaqall.html.bz2 -> ../../1.6.6/alt3/rubyfaqall.html.bz2
   |     `--ruby-1.6.7.tar.bz2
   |--1.7.2
   |  `--alt1
   |     |--ProgrammingRuby-0.3a.tar.bz2 -> ../../1.6.7/alt1/ProgrammingRuby-0.3a.tar.bz2
   |     |--ruby-tcltklib.patch
   |     |--ruby-1.7.2.tar.bz2
   |     |--rubyfaqall.html.bz2 -> ../../1.6.7/alt1/rubyfaqall.html.bz2
   |     `--ruby-1.7-judy.patch.bz2
   |--1.7.3
   |  |--alt1
   |  |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../../1.7.2/alt1/ProgrammingRuby-0.3a.tar.bz2
   |  |  |--ruby-tcltklib.patch
   |  |  |--rubyfaqall.html.bz2 -> ../../1.7.2/alt1/rubyfaqall.html.bz2
   |  |  `--ruby-1.7.3.tar.bz2
   |  |--alt2
   |  |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt1/ProgrammingRuby-0.3a.tar.bz2
   |  |  |--ruby-tcltklib.patch -> ../alt1/ruby-tcltklib.patch
   |  |  |--ruby-net-http-alt.patch
   |  |  |--rubyfaqall.html.bz2 -> ../alt1/rubyfaqall.html.bz2
   |  |  |--ruby-1.7.3.tar.bz2
   |  |  `--ruby-win32ole-extconf-alt.patch
   |  |--alt3
   |  |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt2/ProgrammingRuby-0.3a.tar.bz2
   |  |  |--ruby-tcltklib.patch -> ../alt2/ruby-tcltklib.patch
   |  |  |--ruby-net-http-alt.patch -> ../alt2/ruby-net-http-alt.patch
   |  |  |--rubyfaqall.html.bz2 -> ../alt2/rubyfaqall.html.bz2
   |  |  |--ruby-1.7.3.tar.bz2 -> ../alt2/ruby-1.7.3.tar.bz2
   |  |  `--ruby-win32ole-extconf-alt.patch -> ../alt2/ruby-win32ole-extconf-alt.patch
   |  |--alt4
   |  |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt3/ProgrammingRuby-0.3a.tar.bz2
   |  |  |--ruby-tcltklib.patch -> ../alt3/ruby-tcltklib.patch
   |  |  |--ruby-net-http-alt.patch -> ../alt3/ruby-net-http-alt.patch
   |  |  |--rubyfaqall.html.bz2 -> ../alt3/rubyfaqall.html.bz2
   |  |  |--ruby-1.7.3.tar.bz2
   |  |  `--ruby-win32ole-extconf-alt.patch
   |  |--alt5
   |  |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt4/ProgrammingRuby-0.3a.tar.bz2
   |  |  |--ruby-tcltklib.patch -> ../alt4/ruby-tcltklib.patch
   |  |  |--ruby-net-http-alt.patch -> ../alt4/ruby-net-http-alt.patch
   |  |  |--rubyfaqall.html.bz2 -> ../alt4/rubyfaqall.html.bz2
   |  |  |--ruby-1.7.3.tar.bz2
   |  |  `--ruby-win32ole-extconf-alt.patch -> ../alt4/ruby-win32ole-extconf-alt.patch
   |  |--alt6
   |  |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt5/ProgrammingRuby-0.3a.tar.bz2
   |  |  |--ruby-net-http-alt.patch -> ../alt5/ruby-net-http-alt.patch
   |  |  |--rubyfaqall.html.bz2 -> ../alt5/rubyfaqall.html.bz2
   |  |  |--ruby-1.7.3-cgi.rb-alt.patch
   |  |  `--ruby-1.7.3.tar.bz2 -> ../alt5/ruby-1.7.3.tar.bz2
   |  |--alt7
   |  |  |--ruby-1.7.3.tar.bz2
   |  |  |--ruby-net-http-alt.patch -> ../alt6/ruby-net-http-alt.patch
   |  |  |--ruby-1.7.3-cgi.rb-alt.patch -> ../alt6/ruby-1.7.3-cgi.rb-alt.patch
   |  |  |--ruby-1.7.3-fhs-alt.patch
   |  |  |--ruby-1.7.3-curses-alt.patch
   |  |  |--rubyfaqall.html.bz2
   |  |  |--ProgrammingRuby-0.3a.tar.bz2
   |  |  |--ruby-1.7.3-mkmf-cxx-alt.patch
   |  |  `--ruby-1.7.3-fhs-vendor-alt.patch
   |  |--alt8
   |  |  |--ruby-1.7.3.tar.bz2 -> ../alt7/ruby-1.7.3.tar.bz2
   |  |  |--rubyfaqall.html.bz2 -> ../alt7/rubyfaqall.html.bz2
   |  |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt7/ProgrammingRuby-0.3a.tar.bz2
   |  |  |--ruby-net-http-alt.patch -> ../alt7/ruby-net-http-alt.patch
   |  |  |--ruby-1.7.3-cgi.rb-alt.patch -> ../alt7/ruby-1.7.3-cgi.rb-alt.patch
   |  |  |--ruby-1.7.3-fhs-vendor-alt.patch -> ../alt7/ruby-1.7.3-fhs-vendor-alt.patch
   |  |  |--ruby-1.7.3-curses-alt.patch -> ../alt7/ruby-1.7.3-curses-alt.patch
   |  |  |--ruby-1.7.3-mkmf-cxx-alt.patch -> ../alt7/ruby-1.7.3-mkmf-cxx-alt.patch
   |  |  `--ruby-1.7.3-irb-alt.patch
   |  `--alt9
   |     |--ProgrammingRuby-0.3a.tar.bz2
   |     |--fileutils.rb.patch
   |     |--ruby-1.7.3-cgi.rb-alt.patch
   |     |--ruby-1.7.3-curses-alt.patch
   |     |--ruby-1.7.3-fhs-vendor-alt.patch
   |     |--ruby-1.7.3-mkmf-cxx-alt.patch
   |     |--ruby-1.7.3.tar.bz2
   |     `--rubyfaqall.html.bz2
   `--1.8
      |--alt1
      |  |--ProgrammingRuby-0.3a.tar.bz2
      |  |--fileutils.rb.patch
      |  |--ruby-1.7.3-curses-alt.patch
      |  |--ruby-1.7.3-fhs-vendor-alt.patch
      |  |--ruby-1.7.3-mkmf-cxx-alt.patch
      |  |--ruby-1.8.tar.bz2
      |  |--rubyfaqall.html.bz2
      |  |--features-ruby18.txt
      |  |--peters.pdf
      |  |--rubyfaq_a4.pdf
      |  `--rubyesque.tar.gz
      |--alt2
      |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt1/ProgrammingRuby-0.3a.tar.bz2
      |  |--features-ruby18.txt -> ../alt1/features-ruby18.txt
      |  |--fileutils.rb.patch -> ../alt1/fileutils.rb.patch
      |  |--peters.pdf -> ../alt1/peters.pdf
      |  |--ruby-1.7.3-curses-alt.patch -> ../alt1/ruby-1.7.3-curses-alt.patch
      |  |--ruby-1.7.3-fhs-vendor-alt.patch -> ../alt1/ruby-1.7.3-fhs-vendor-alt.patch
      |  |--ruby-1.7.3-mkmf-cxx-alt.patch -> ../alt1/ruby-1.7.3-mkmf-cxx-alt.patch
      |  |--ruby-1.8.tar.bz2 -> ../alt1/ruby-1.8.tar.bz2
      |  |--rubyesque.tar.gz -> ../alt1/rubyesque.tar.gz
      |  `--rubyfaq_a4.pdf -> ../alt1/rubyfaq_a4.pdf
      |--alt3
      |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt2/ProgrammingRuby-0.3a.tar.bz2
      |  |--features-ruby18.txt -> ../alt2/features-ruby18.txt
      |  |--fileutils.rb.patch -> ../alt2/fileutils.rb.patch
      |  |--peters.pdf -> ../alt2/peters.pdf
      |  |--ruby-1.7.3-curses-alt.patch -> ../alt2/ruby-1.7.3-curses-alt.patch
      |  |--ruby-1.7.3-fhs-vendor-alt.patch -> ../alt2/ruby-1.7.3-fhs-vendor-alt.patch
      |  |--ruby-1.7.3-mkmf-cxx-alt.patch -> ../alt2/ruby-1.7.3-mkmf-cxx-alt.patch
      |  |--ruby-1.8.tar.bz2
      |  |--rubyesque.tar.gz -> ../alt2/rubyesque.tar.gz
      |  `--rubyfaq_a4.pdf -> ../alt2/rubyfaq_a4.pdf
      |--alt4
      |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt3/ProgrammingRuby-0.3a.tar.bz2
      |  |--features-ruby18.txt -> ../alt3/features-ruby18.txt
      |  |--fileutils.rb.patch -> ../alt3/fileutils.rb.patch
      |  |--peters.pdf -> ../alt3/peters.pdf
      |  |--ruby-1.7.3-fhs-vendor-alt.patch -> ../alt3/ruby-1.7.3-fhs-vendor-alt.patch
      |  |--ruby-1.7.3-mkmf-cxx-alt.patch -> ../alt3/ruby-1.7.3-mkmf-cxx-alt.patch
      |  |--ruby-1.8.tar.bz2 -> ../alt3/ruby-1.8.tar.bz2
      |  |--rubyesque.tar.gz -> ../alt3/rubyesque.tar.gz
      |  `--rubyfaq_a4.pdf -> ../alt3/rubyfaq_a4.pdf
      |--alt5
      |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt4/ProgrammingRuby-0.3a.tar.bz2
      |  |--features-ruby18.txt -> ../alt4/features-ruby18.txt
      |  |--fileutils.rb.patch -> ../alt4/fileutils.rb.patch
      |  |--peters.pdf -> ../alt4/peters.pdf
      |  |--ruby-1.7.3-fhs-vendor-alt.patch -> ../alt4/ruby-1.7.3-fhs-vendor-alt.patch
      |  |--ruby-1.7.3-mkmf-cxx-alt.patch -> ../alt4/ruby-1.7.3-mkmf-cxx-alt.patch
      |  |--ruby-1.8.tar.bz2
      |  |--rubyesque.tar.gz -> ../alt4/rubyesque.tar.gz
      |  `--rubyfaq_a4.pdf -> ../alt4/rubyfaq_a4.pdf
      |--alt6
      |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt5/ProgrammingRuby-0.3a.tar.bz2
      |  |--features-ruby18.txt -> ../alt5/features-ruby18.txt
      |  |--fileutils.rb.patch -> ../alt5/fileutils.rb.patch
      |  |--peters.pdf -> ../alt5/peters.pdf
      |  |--ruby-1.7.3-fhs-vendor-alt.patch -> ../alt5/ruby-1.7.3-fhs-vendor-alt.patch
      |  |--ruby-1.7.3-mkmf-cxx-alt.patch -> ../alt5/ruby-1.7.3-mkmf-cxx-alt.patch
      |  |--ruby-1.8.tar.bz2
      |  |--rubyesque.tar.gz -> ../alt5/rubyesque.tar.gz
      |  `--rubyfaq_a4.pdf -> ../alt5/rubyfaq_a4.pdf
      `--alt7
         |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt6/ProgrammingRuby-0.3a.tar.bz2
         |--features-ruby18.txt -> ../alt6/features-ruby18.txt
         |--fileutils.rb.patch -> ../alt6/fileutils.rb.patch
         |--peters.pdf -> ../alt6/peters.pdf
         |--ruby-1.7.3-fhs-vendor-alt.patch -> ../alt6/ruby-1.7.3-fhs-vendor-alt.patch
         |--ruby-1.7.3-mkmf-cxx-alt.patch -> ../alt6/ruby-1.7.3-mkmf-cxx-alt.patch
         |--ruby-1.8.tar.bz2
         |--rubyesque.tar.gz -> ../alt6/rubyesque.tar.gz
         `--rubyfaq_a4.pdf -> ../alt6/rubyfaq_a4.pdf

Как можно заметить, неизменившиеся части пакета хранятся в
единственном экземпляре в той версии, где они впервые встретились. Все
последующие версии ссылаются на них при помощи символических
ссылок. Так как мы заранее ограничили область видимости хранилища
только sandman, то проблемы с вложенностью символических ссылок
решаются только на уровне языка, на котором реализован sandman (Tcl).

Так как при мы отказались от хранения исходников в SCM, то помещение
исходников в хранилище, получение их оттуда и операции по сборке
пакетов в Sandman осуществляются посредством собственной утилиты
sandcl. На самом деле, даже интеграция с SCM (в нашем случае -- с CVS)
выполнена тоже через утилиту sandcl, так что по-прежнему остается
единственная точка входа в хранилище.

Для добавления исходников пакета используется команда addsources
утилиты sandcl:

	sandcl addsources имя_пакета исходники

При выполнении этой команды переданные исходники помещаются на верхний
уровень хранилища для соответствующего пакета. В момент изменения
spec-файла в SCM происходит вызов sandcl с параметрами проверки
корректности новой версии spec-файла и изменения состояния хранилища в
случае успешности проверки. Выглядит это следующим образом:

1) валидируются значения Serial, Name, Version, Release, Group,
  changelog;

2) выясняется, содержит ли предлагаемый к commit'у spec измененные SVR
  относительно последней ревизии в CVS, при увеличенных происходит
  простановка cvs tag вида $branch-$serial-$version-$release на
  последнюю ревизию spec в CVS, ситуация с уменьшенными значениями
  расценивается как ошибочная. Дополнительно происходит блокировка
  создания тегов указанного вида напрямую пользователем;

3) для каждого указанного в spec файла исходников производятся
  следующие действия:

  3.1) проверяется его наличие в корневой для этого пакета ($sources/$name)
       директории;

  3.2) если таковой находится, он переносятся на 3 уровня
       (serial/version/release) ниже;

  3.3) иначе, проверяется его наличие в name/serial/version/release);

  3.4) иначе, проверяется его наличие в name/serial/version/*;

  3.5) иначе, проверяется его наличие в name/serial/*/*;

  3.6) иначе ситуация считается ошибочной;
	
По возникновению любой из ошибочных ситуаций commit отвергается,
директория $sources/$name очищается.

Обратите внимание, что хранение для каждого пакета в SCM только
spec-файла также делает ненужной со стороны SCM поддержку changesets,
то есть отслеживания групповых изменений файлов, поскольку каждому
пакету принадлежит только один файл в SCM -- его spec-файл.

Состояние SCM в результате выглядит примерно так:
$ cvs stat -v ruby
===================================================================
File: ruby              Status: Up-to-date

   Working revision:    1.87
   Repository revision: 1.87    /data/cvs/alt/packages/ruby,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

   Existing Tags:
        head-0-1_8-alt6                 (revision: 1.86)
        head-0-1_8-alt5                 (revision: 1.85)
        head-0-1_8-alt4                 (revision: 1.82)
        head-0-1_8-alt3                 (revision: 1.79)
        head-0-1_8-alt2                 (revision: 1.75)
        head-0-1_7_3-alt7               (revision: 1.50)
        head-0-1_7_3-alt4               (revision: 1.33)
        head-0-1_7_3-alt3               (revision: 1.29)
        head-0-1_7_3-alt2               (revision: 1.28)
        head-0-1_7_3-alt1               (revision: 1.21)
        head-0-1_7_2-alt1               (revision: 1.19)
        head-0-1_6_7-alt1               (revision: 1.4)
        head-0-1_6_6-alt3               (revision: 1.1)

Более дружелюбную информацию с точки зрения хранилища можно получить
командой sandcl queryver, которая возвращает список имеющихся в
репозитарии версий указанного пакета или группы пакетов:

$ sandcl queryver ruby
ruby: 0-1.8-alt2 0-1.8-alt3 0-1.8-alt4 0-1.8-alt5 0-1.8-alt6 0-1.8-alt6

Получить исходники пакета можно командой sandcl getsources:

	 sandcl getsources [опции] имя_пакета [шаблон]

где в качестве опций может фигурировать опция 

        -pkgver версия

позволяющая указать нужную версию пакета согласно нотации, выводимой
командой sandcl queryver (S-V-R). Указание шаблона позволяет получить
не все исходники, а только те, которые совпадают с указанным шаблоном.

Таким образом, можно сделать несколько выводов:

1) Хранилище может быть организовано даже с использованием
   несовершенных в некоторых отношениях свободных SCM, таких как
   CVS. От SCM требуется только наличие механизма запуска внешних
   программ при выполнении операций изменения spec-файлов, а так же
   возможность хранения помеченных состояний файлов (тегов).

2) Многоуровневая древовидная система хранения версий пакетов не
   накладывает ограничений на будущую реализацию хранилища, проста в
   реализации и в принципе может быть распределенной при использовании
   в качестве файлового хранилища распределенной файловой системы типа
   OpenAFS.

3) Реализация хранилища на базе Sandman не привязана к конкретной SCM,
   напротив, интеграция с любой SCM тривиальна.

Предлагаемое решение для ALT Linux Sisyphus.

Sandman может быть использован для организации версионированного
хранилища для ALT Linux Sisyphus следующим образом:

1) Любой пакет, приходящий в ALT Linux Sisyphus, после пересборки
   автоматически помещается в sandman:
  
	rpmcpio foo-1.2.3-alt1.src.rpm | sandcl addsources foo

	commitlog=$(rpmquery --lastchange -p foo-1.2.3-alt1.src.rpm)

	cvs commit -m "$commitlog" foo

	где foo в последней строке -- spec-файл пакета foo. 

   Sandman принципиально требует того, чтобы в SCM имя spec-файла
   пакета совпадало с именем пакета -- это тот минимум, который
   требуется для обеспечения непротиворечивости хранилища. 

   Согласитесь, что, например, иметь пакет openldap и spec-файл для
   него под именем openldap-2.1.21.spec несколько неосмысленно -- как
   должен будет называться spec-файл в случае увеличения версии
   пакета?

   Отбрасывание расширения .spec также необходимо для упрощения логики
   реализации хранилища.

2) Любой разработчик ALT Linux Team получает доступ к sandman для
   выполнения следующих запросов:

	      sandcl querynames
	      sandcl queryver
	      sandcl query
	      sandcl getsources
	      
   
   Все эти команды позволяют общаться с хранилищем в режиме "только
   для чтения". Из нерассмотренных выше, команда sandcl querynames
   выводит список имеющихся в хранилище пакетов, а sandcl query
   позвращает граф-описание зависимостей указанного пакета в формате
   GraphViz dot.

3) Любой разработчик ALT Linux Team получает доступ по чтению к
   CVS-модулю, в котором хранятся spec-файлы пакетов.

4) Каждый выпущенный дистрибутив помещается в хранилище с
   использованием возможностей sandman по ведению множественных
   репозитариев, при этом spec-файлы соответствующих пакетов
   помещаются в тот же модуль, но в ветку с именем дистрибутива и его
   версией, например, master_2_2.

5) Все обновления в безопасности для уже выпущенных дистрибутивов
   автоматически помещаются в sandman в соответствующий
   репозитарий-ветку. Таким образом, для выпущенных дистрибутивов
   имеется всегда актуальное состояние репозитария и сохраняется
   история изменений. В частности, это позволит несколько ослабить
   требование несобирания новых версий в updates, поскольку контроль
   как зависимостей, так и версий будет значительно проще.

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


-- 
/ Alexander Bokovoy
---
You will overcome the attacks of jealous associates.

Re: [devel] sandman на cvs.altlinux.org

[Anton Farygin]

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

Alexander Bokovoy пишет:
> On Mon, Aug 04, 2003 at 12:50:35PM +0300, Alexander Bokovoy wrote:
> 
>>On Mon, Aug 04, 2003 at 01:08:59PM +0400, Dmitry V. Levin wrote:
>>
>>>On Mon, Aug 04, 2003 at 01:03:57PM +0400, Anton Farygin wrote:
>>>
>>>>>1. Уточнить планируемую структуру репозитария, который, напоминаю, будет
>>>>>  readonly (пока не придумаем распределённый репозитарий).
>>>>
>>>>Упс... а зачем нам нужен readonly репозитарий ? Толку то от него ?
>>>
>>>Чтобы каждый мог сделать checkout/update/diff с минимальными затратами на
>>>трафик.
>>>
>>>Для того, чтобы сделать rw, нужен распределённый репозитарий, о котором
>>>сейчас речь не идёт, ибо он даже не разработан.
>>
>>Господа, я напишу вечером подробности о своем видении того, что
>>предлагается и как в эту схему вписывается использование sandman в
>>read-only режиме. Писал, писал, написал большое письмо и оно мистически
>>пропало вместе с процессом vim-а, в котором это происходило. Даже в TMPDIR
>>не осталось следов. :(
> 
> Итак, опус прикладывается:


<опус прочтен и поскипан>

Все хорошо и нужно внедрять.

Один только вопрос: в чем поможет нам эта схема для, например, 
разработки ядра - если там требуется активная read-write работа с 
репозитарием для всех мантейнеров ядерных пакетов. ?

можно ли сделать часть репозитария доступным на запись ?

Rgds,
Rider

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

Re: [devel] sandman на cvs.altlinux.org

[Alexander Bokovoy]

On Tue, Aug 05, 2003 at 02:45:16PM +0400, Anton Farygin wrote:
> >>>сейчас речь не идёт, ибо он даже не разработан.
> >>
> >>Господа, я напишу вечером подробности о своем видении того, что
> >>предлагается и как в эту схему вписывается использование sandman в
> >>read-only режиме. Писал, писал, написал большое письмо и оно мистически
> >>пропало вместе с процессом vim-а, в котором это происходило. Даже в TMPDIR
> >>не осталось следов. :(
> >
> >Итак, опус прикладывается:
> 
> 
> <опус прочтен и поскипан>
> 
> Все хорошо и нужно внедрять.
> 
> Один только вопрос: в чем поможет нам эта схема для, например, 
> разработки ядра - если там требуется активная read-write работа с 
> репозитарием для всех мантейнеров ядерных пакетов. ?
> 
> можно ли сделать часть репозитария доступным на запись ?
Можно. Я все же описал схему, которую мы обсуждали с Дмитрием на Фесте.
Что касается полноценного использования sandman, как это делаем здесь мы
-- вопрос риторический.

-- 
/ Alexander Bokovoy
---
Johnson's First Law:
	When any mechanical contrivance fails, it will do so at the
	most inconvenient possible time.

Re: [devel] sandman на cvs.altlinux.org

[Anton Farygin]

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

Alexander Bokovoy пишет:
> On Tue, Aug 05, 2003 at 02:45:16PM +0400, Anton Farygin wrote:
> 
>>>>>сейчас речь не идёт, ибо он даже не разработан.
>>>>
>>>>Господа, я напишу вечером подробности о своем видении того, что
>>>>предлагается и как в эту схему вписывается использование sandman в
>>>>read-only режиме. Писал, писал, написал большое письмо и оно мистически
>>>>пропало вместе с процессом vim-а, в котором это происходило. Даже в TMPDIR
>>>>не осталось следов. :(
>>>
>>>Итак, опус прикладывается:
>>
>>
>><опус прочтен и поскипан>
>>
>>Все хорошо и нужно внедрять.
>>
>>Один только вопрос: в чем поможет нам эта схема для, например, 
>>разработки ядра - если там требуется активная read-write работа с 
>>репозитарием для всех мантейнеров ядерных пакетов. ?
>>
>>можно ли сделать часть репозитария доступным на запись ?
> 
> Можно. Я все же описал схему, которую мы обсуждали с Дмитрием на Фесте.
> Что касается полноценного использования sandman, как это делаем здесь мы
> -- вопрос риторический.
> 

Полноценного использования для хранения и изменения, но не для сборки.

Сборку все-таки лучше через hasher проводить.

Rgds,
Rider

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

Re: [devel] sandman на cvs.altlinux.org

[Alexey I. Froloff]

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

* Anton Farygin <rider@altlinux.com> [030805 15:24]:
> Сборку все-таки лучше через hasher проводить.
Чем лучше?

-- 
Regards, Sir Raorn.
-------------------
Костя появится через неделю, а пакет с  ядром он уходя поставил
собираться :-)
		-- aen in devel@

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

[devel] Re: sandman на cvs.altlinux.org

[Vitaly Ostanin]

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

On Tue, 5 Aug 2003 15:35:29 +0400
"Alexey I. Froloff" <sir_raorn@immo.ru> wrote:

> * Anton Farygin <rider@altlinux.com> [030805 15:24]:
> > Сборку все-таки лучше через hasher проводить.
> Чем лучше?

Один в один, то же самое хотел спросить :)

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

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

Re: [devel] sandman на cvs.altlinux.org

[Anton Farygin]

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

Alexey I. Froloff пишет:
> * Anton Farygin <rider@altlinux.com> [030805 15:24]:
> 
>>Сборку все-таки лучше через hasher проводить.
> 
> Чем лучше?
Тем, что incoming разгребается hasher'ом .

Rgds,
Rider

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

Re: [devel] sandman на cvs.altlinux.org

[Alexey I. Froloff]

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

* Anton Farygin <rider@altlinux.com> [030805 16:20]:
> >>Сборку все-таки лучше через hasher проводить.
> >Чем лучше?
> Тем, что incoming разгребается hasher'ом .
Нет, а чем это лучше, чем родной sandman'овский пересборщик?

P.S. Не флейма ради, я просто понять хочу.

-- 
Regards, Sir Raorn.
-------------------
осталось некоторое количество непересобранных, но нужных пакетов.
Мы их постепенно пересобираем, но некоторые не умеем тестировать.
		-- aen in devel@

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

Re: [devel] sandman на cvs.altlinux.org

[Dmitry V. Levin]

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

On Tue, Aug 05, 2003 at 12:32:39PM +0300, Alexander Bokovoy wrote:
> Одним из недостатков процесса разработки в рамках проекта ALT Linux
> Team является отсутствие истории проекта, выражающееся в
> невозможности отслеживания изменений в пакетах на протяжении их
> эволюционирования, поскольку в любой момент времени доступен лишь
> самый последний вариант каждого пакета в рамках ALT Linux Sisyphus и,
> дискретно, версии, включаемые в выпускаемые дистрибутивы ALT Linux
> Master, Junior, etc. К сожалению, такой подход ограничивает
> возможности разработчиков по полноценному развитию проекта, поскольку
> в таком случае каждый вынужден самостоятельно вести историю
> необходимых ему (или поддерживаемых) пакетов, а также осложняет
> разработку тех пакетов, которые поддерживаются распределенной группой
> разработчиков.

Небольшая поправка: речь идёт об отсутствии публично доступного ресурса.

> Решением этой проблемы стало бы создание централизованного хранилища
> всех версий пакетов, попадающих в ALT Linux Sisyphus как в основной
> репозитарий. Такое централизованное хранилище могло бы служить
> референтной базой данных всего проекта и в дальнейшем послужило бы
> основой для распределенной системы разработки, отсутствие которой
> ощущается все острее с ростом количества разработчиков и проектов,
> выполняемых на пакетной базе ALT Linux Sisyphus.
> 
> Каковы же требования, предъявляемые к централизованному хранилищу?
> Нам кажется, что таковыми могут быть следующие положения:
> 
> 1) Возможность хранения версий исходных пакетов, как для исходных
>    текстов, так и для spec-файлов.
> 
> 2) Возможность автоматического обновления хранилища при изменении ALT
>    Linux Sisyphus. На первом этапе это обновление должно быть
>    единственным способом изменения хранилища, для всех остальных
>    хранилище должно быть доступным только по чтению.
> 
> 3) Возможность получения любой из хранящихся версий пакета с
>    максимальным уровнем грануляции (пакет целиком, некоторый набор
>    исходных файлов, spec-файл).

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

> 4) Контроль за зависимостями пакетов -- пакеты, которые невозможно
>    пересобрать на текущей версии репозитария, в хранилище и в ALT
>    Linux Sisyphus попадать не должны.
> 
> Все эти требования связаны только с хранением версий пакетов и
> обеспечением их целостности относительно того момента, когда пакеты
> попадают в хранилище. В дальнейшем появятся и другие требования,
> связанные с распределенной системой разработки.
> 
> В связи с тем, что пакеты RPM представляют собой набор как текстовых,
> так и бинарных объектов, то следует подробнее проработать схему
> хранения пакетов. Существующие свободные системы SCM (software 
> configuration management), к сожалению, не позволяют в достаточной
> мере гибко хранить версии бинарных объектов, поэтому представляется
> осмысленным использовать некоторую внешнию схему версионирования
> бинарных объектов в пакетах RPM, управляемую посредством
> контролируемых в SCM текстовых объектов пакета. Если обратиться к
> содержимому любого исходного пакета RPM, то можно увидеть, что только
> один текстовый объект в нем представляет достаточно информации для
> контроля всех остальных -- текстовых и бинарных -- объектов пакета и
> этим контролирующим объектом является spec-файл.

Это не всегда так.
Зачастую среди множества исходных файлов данного пакета есть и вполне
плоские текстовые файлы.

> Spec-файл содержит исчерпывающую информацию, необходимую для контроля
> пакета, включая его версию и подчиненные исходные файлы (исходники,
> заплатки, конфигурационные файлы и т.д.). Благодаря наличию в пакете
> RPM в ALT Linux режима предварительного анализа spec-файла (опция -bE
> утилиты rpmbuild) возможна регуляризация spec-файла (раскрытие
> макросов в именах файлов) с последующим вычленением составных
> частей. Режим предварительного анализа также позволяет обнаружить
> синтаксические ошибки в коде spec-файла и тем самым оградить хранилище
> от заведомо неработоспособных сборок пакетов.
> 
> Таким образом, поместив spec-файл под контроль SCM с дополнительной
> интеграцией имеющихся средств самого RPM, можно добиться четкого и
> непротиворечивого управления содержимым исходного пакета. Какую же
> структуру хранения можно использовать для этих целей?
> 
> В рамках проекта по построению сборочной и тестовой среды (BTE) нами
> был создан механизм, позволяющий эффективно хранить и версионировать
> пакеты. Этот механизм реализован в программе Sandman (пакеты sandman и
> sandman-server). Sandman использует следующую структуру хранения:
> 
> 1) Spec-файлы хранятся в CVS в отдельном модуле
> 
> 2) Операции изменения spec-файла в CVS перехватываются и анализируются
> 
> 3) По результатам анализа происходит версионирование и изменение
>    исходных файлов пакета
> 
> 4) Исходные файлы пакета хранятся в многоуровневой древовидной
>    структуре, доступ к которой напрямую невозможен
> 
> Таким образом, существует единая точка входа в хранилище -- spec-файл
> в CVS, через которую осуществляется изменение всего пакета. Каким же
> образом хранятся остальные части пакета? Многоуровневая древовидная
> структура представляет собой систему подкаталогов следующего вида:
> 
> уровень1   уровень2 уровень3 уровень4   уровень5
> имя_пакета 
>            serial
>                     version
>                              release
>                                        исходники
> 
> Например, для пакета Ruby эта структура выглядит следующим образом:
> 
> /data/sandman/sisyphus/sources/ruby/
> `--0
>    |--1.6.6
>    |  `--alt3
>    |     |--rubyfaqall.html.bz2
>    |     |--ruby-1.6.6.tar.bz2
>    |     `--ProgrammingRuby-0.3a.tar.bz2
>    |--1.6.7
>    |  `--alt1
>    |     |--ProgrammingRuby-0.3a.tar.bz2 -> ../../1.6.6/alt3/ProgrammingRuby-0.3a.tar.bz2
>    |     |--rubyfaqall.html.bz2 -> ../../1.6.6/alt3/rubyfaqall.html.bz2
>    |     `--ruby-1.6.7.tar.bz2
>    |--1.7.2
>    |  `--alt1
>    |     |--ProgrammingRuby-0.3a.tar.bz2 -> ../../1.6.7/alt1/ProgrammingRuby-0.3a.tar.bz2
>    |     |--ruby-tcltklib.patch
>    |     |--ruby-1.7.2.tar.bz2
>    |     |--rubyfaqall.html.bz2 -> ../../1.6.7/alt1/rubyfaqall.html.bz2
>    |     `--ruby-1.7-judy.patch.bz2
>    |--1.7.3
>    |  |--alt1
>    |  |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../../1.7.2/alt1/ProgrammingRuby-0.3a.tar.bz2
>    |  |  |--ruby-tcltklib.patch
>    |  |  |--rubyfaqall.html.bz2 -> ../../1.7.2/alt1/rubyfaqall.html.bz2
>    |  |  `--ruby-1.7.3.tar.bz2
>    |  |--alt2
>    |  |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt1/ProgrammingRuby-0.3a.tar.bz2
>    |  |  |--ruby-tcltklib.patch -> ../alt1/ruby-tcltklib.patch
>    |  |  |--ruby-net-http-alt.patch
>    |  |  |--rubyfaqall.html.bz2 -> ../alt1/rubyfaqall.html.bz2
>    |  |  |--ruby-1.7.3.tar.bz2
>    |  |  `--ruby-win32ole-extconf-alt.patch
>    |  |--alt3
>    |  |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt2/ProgrammingRuby-0.3a.tar.bz2
>    |  |  |--ruby-tcltklib.patch -> ../alt2/ruby-tcltklib.patch
>    |  |  |--ruby-net-http-alt.patch -> ../alt2/ruby-net-http-alt.patch
>    |  |  |--rubyfaqall.html.bz2 -> ../alt2/rubyfaqall.html.bz2
>    |  |  |--ruby-1.7.3.tar.bz2 -> ../alt2/ruby-1.7.3.tar.bz2
>    |  |  `--ruby-win32ole-extconf-alt.patch -> ../alt2/ruby-win32ole-extconf-alt.patch
>    |  |--alt4
>    |  |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt3/ProgrammingRuby-0.3a.tar.bz2
>    |  |  |--ruby-tcltklib.patch -> ../alt3/ruby-tcltklib.patch
>    |  |  |--ruby-net-http-alt.patch -> ../alt3/ruby-net-http-alt.patch
>    |  |  |--rubyfaqall.html.bz2 -> ../alt3/rubyfaqall.html.bz2
>    |  |  |--ruby-1.7.3.tar.bz2
>    |  |  `--ruby-win32ole-extconf-alt.patch
>    |  |--alt5
>    |  |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt4/ProgrammingRuby-0.3a.tar.bz2
>    |  |  |--ruby-tcltklib.patch -> ../alt4/ruby-tcltklib.patch
>    |  |  |--ruby-net-http-alt.patch -> ../alt4/ruby-net-http-alt.patch
>    |  |  |--rubyfaqall.html.bz2 -> ../alt4/rubyfaqall.html.bz2
>    |  |  |--ruby-1.7.3.tar.bz2
>    |  |  `--ruby-win32ole-extconf-alt.patch -> ../alt4/ruby-win32ole-extconf-alt.patch
>    |  |--alt6
>    |  |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt5/ProgrammingRuby-0.3a.tar.bz2
>    |  |  |--ruby-net-http-alt.patch -> ../alt5/ruby-net-http-alt.patch
>    |  |  |--rubyfaqall.html.bz2 -> ../alt5/rubyfaqall.html.bz2
>    |  |  |--ruby-1.7.3-cgi.rb-alt.patch
>    |  |  `--ruby-1.7.3.tar.bz2 -> ../alt5/ruby-1.7.3.tar.bz2
>    |  |--alt7
>    |  |  |--ruby-1.7.3.tar.bz2
>    |  |  |--ruby-net-http-alt.patch -> ../alt6/ruby-net-http-alt.patch
>    |  |  |--ruby-1.7.3-cgi.rb-alt.patch -> ../alt6/ruby-1.7.3-cgi.rb-alt.patch
>    |  |  |--ruby-1.7.3-fhs-alt.patch
>    |  |  |--ruby-1.7.3-curses-alt.patch
>    |  |  |--rubyfaqall.html.bz2
>    |  |  |--ProgrammingRuby-0.3a.tar.bz2
>    |  |  |--ruby-1.7.3-mkmf-cxx-alt.patch
>    |  |  `--ruby-1.7.3-fhs-vendor-alt.patch
>    |  |--alt8
>    |  |  |--ruby-1.7.3.tar.bz2 -> ../alt7/ruby-1.7.3.tar.bz2
>    |  |  |--rubyfaqall.html.bz2 -> ../alt7/rubyfaqall.html.bz2
>    |  |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt7/ProgrammingRuby-0.3a.tar.bz2
>    |  |  |--ruby-net-http-alt.patch -> ../alt7/ruby-net-http-alt.patch
>    |  |  |--ruby-1.7.3-cgi.rb-alt.patch -> ../alt7/ruby-1.7.3-cgi.rb-alt.patch
>    |  |  |--ruby-1.7.3-fhs-vendor-alt.patch -> ../alt7/ruby-1.7.3-fhs-vendor-alt.patch
>    |  |  |--ruby-1.7.3-curses-alt.patch -> ../alt7/ruby-1.7.3-curses-alt.patch
>    |  |  |--ruby-1.7.3-mkmf-cxx-alt.patch -> ../alt7/ruby-1.7.3-mkmf-cxx-alt.patch
>    |  |  `--ruby-1.7.3-irb-alt.patch
>    |  `--alt9
>    |     |--ProgrammingRuby-0.3a.tar.bz2
>    |     |--fileutils.rb.patch
>    |     |--ruby-1.7.3-cgi.rb-alt.patch
>    |     |--ruby-1.7.3-curses-alt.patch
>    |     |--ruby-1.7.3-fhs-vendor-alt.patch
>    |     |--ruby-1.7.3-mkmf-cxx-alt.patch
>    |     |--ruby-1.7.3.tar.bz2
>    |     `--rubyfaqall.html.bz2
>    `--1.8
>       |--alt1
>       |  |--ProgrammingRuby-0.3a.tar.bz2
>       |  |--fileutils.rb.patch
>       |  |--ruby-1.7.3-curses-alt.patch
>       |  |--ruby-1.7.3-fhs-vendor-alt.patch
>       |  |--ruby-1.7.3-mkmf-cxx-alt.patch
>       |  |--ruby-1.8.tar.bz2
>       |  |--rubyfaqall.html.bz2
>       |  |--features-ruby18.txt
>       |  |--peters.pdf
>       |  |--rubyfaq_a4.pdf
>       |  `--rubyesque.tar.gz
>       |--alt2
>       |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt1/ProgrammingRuby-0.3a.tar.bz2
>       |  |--features-ruby18.txt -> ../alt1/features-ruby18.txt
>       |  |--fileutils.rb.patch -> ../alt1/fileutils.rb.patch
>       |  |--peters.pdf -> ../alt1/peters.pdf
>       |  |--ruby-1.7.3-curses-alt.patch -> ../alt1/ruby-1.7.3-curses-alt.patch
>       |  |--ruby-1.7.3-fhs-vendor-alt.patch -> ../alt1/ruby-1.7.3-fhs-vendor-alt.patch
>       |  |--ruby-1.7.3-mkmf-cxx-alt.patch -> ../alt1/ruby-1.7.3-mkmf-cxx-alt.patch
>       |  |--ruby-1.8.tar.bz2 -> ../alt1/ruby-1.8.tar.bz2
>       |  |--rubyesque.tar.gz -> ../alt1/rubyesque.tar.gz
>       |  `--rubyfaq_a4.pdf -> ../alt1/rubyfaq_a4.pdf
>       |--alt3
>       |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt2/ProgrammingRuby-0.3a.tar.bz2
>       |  |--features-ruby18.txt -> ../alt2/features-ruby18.txt
>       |  |--fileutils.rb.patch -> ../alt2/fileutils.rb.patch
>       |  |--peters.pdf -> ../alt2/peters.pdf
>       |  |--ruby-1.7.3-curses-alt.patch -> ../alt2/ruby-1.7.3-curses-alt.patch
>       |  |--ruby-1.7.3-fhs-vendor-alt.patch -> ../alt2/ruby-1.7.3-fhs-vendor-alt.patch
>       |  |--ruby-1.7.3-mkmf-cxx-alt.patch -> ../alt2/ruby-1.7.3-mkmf-cxx-alt.patch
>       |  |--ruby-1.8.tar.bz2
>       |  |--rubyesque.tar.gz -> ../alt2/rubyesque.tar.gz
>       |  `--rubyfaq_a4.pdf -> ../alt2/rubyfaq_a4.pdf
>       |--alt4
>       |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt3/ProgrammingRuby-0.3a.tar.bz2
>       |  |--features-ruby18.txt -> ../alt3/features-ruby18.txt
>       |  |--fileutils.rb.patch -> ../alt3/fileutils.rb.patch
>       |  |--peters.pdf -> ../alt3/peters.pdf
>       |  |--ruby-1.7.3-fhs-vendor-alt.patch -> ../alt3/ruby-1.7.3-fhs-vendor-alt.patch
>       |  |--ruby-1.7.3-mkmf-cxx-alt.patch -> ../alt3/ruby-1.7.3-mkmf-cxx-alt.patch
>       |  |--ruby-1.8.tar.bz2 -> ../alt3/ruby-1.8.tar.bz2
>       |  |--rubyesque.tar.gz -> ../alt3/rubyesque.tar.gz
>       |  `--rubyfaq_a4.pdf -> ../alt3/rubyfaq_a4.pdf
>       |--alt5
>       |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt4/ProgrammingRuby-0.3a.tar.bz2
>       |  |--features-ruby18.txt -> ../alt4/features-ruby18.txt
>       |  |--fileutils.rb.patch -> ../alt4/fileutils.rb.patch
>       |  |--peters.pdf -> ../alt4/peters.pdf
>       |  |--ruby-1.7.3-fhs-vendor-alt.patch -> ../alt4/ruby-1.7.3-fhs-vendor-alt.patch
>       |  |--ruby-1.7.3-mkmf-cxx-alt.patch -> ../alt4/ruby-1.7.3-mkmf-cxx-alt.patch
>       |  |--ruby-1.8.tar.bz2
>       |  |--rubyesque.tar.gz -> ../alt4/rubyesque.tar.gz
>       |  `--rubyfaq_a4.pdf -> ../alt4/rubyfaq_a4.pdf
>       |--alt6
>       |  |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt5/ProgrammingRuby-0.3a.tar.bz2
>       |  |--features-ruby18.txt -> ../alt5/features-ruby18.txt
>       |  |--fileutils.rb.patch -> ../alt5/fileutils.rb.patch
>       |  |--peters.pdf -> ../alt5/peters.pdf
>       |  |--ruby-1.7.3-fhs-vendor-alt.patch -> ../alt5/ruby-1.7.3-fhs-vendor-alt.patch
>       |  |--ruby-1.7.3-mkmf-cxx-alt.patch -> ../alt5/ruby-1.7.3-mkmf-cxx-alt.patch
>       |  |--ruby-1.8.tar.bz2
>       |  |--rubyesque.tar.gz -> ../alt5/rubyesque.tar.gz
>       |  `--rubyfaq_a4.pdf -> ../alt5/rubyfaq_a4.pdf
>       `--alt7
>          |--ProgrammingRuby-0.3a.tar.bz2 -> ../alt6/ProgrammingRuby-0.3a.tar.bz2
>          |--features-ruby18.txt -> ../alt6/features-ruby18.txt
>          |--fileutils.rb.patch -> ../alt6/fileutils.rb.patch
>          |--peters.pdf -> ../alt6/peters.pdf
>          |--ruby-1.7.3-fhs-vendor-alt.patch -> ../alt6/ruby-1.7.3-fhs-vendor-alt.patch
>          |--ruby-1.7.3-mkmf-cxx-alt.patch -> ../alt6/ruby-1.7.3-mkmf-cxx-alt.patch
>          |--ruby-1.8.tar.bz2
>          |--rubyesque.tar.gz -> ../alt6/rubyesque.tar.gz
>          `--rubyfaq_a4.pdf -> ../alt6/rubyfaq_a4.pdf
> 
> Как можно заметить, неизменившиеся части пакета хранятся в
> единственном экземпляре в той версии, где они впервые встретились. Все
> последующие версии ссылаются на них при помощи символических
> ссылок. Так как мы заранее ограничили область видимости хранилища
> только sandman, то проблемы с вложенностью символических ссылок
> решаются только на уровне языка, на котором реализован sandman (Tcl).
> 
> Так как при мы отказались от хранения исходников в SCM, то помещение
> исходников в хранилище, получение их оттуда и операции по сборке
> пакетов в Sandman осуществляются посредством собственной утилиты
> sandcl. На самом деле, даже интеграция с SCM (в нашем случае -- с CVS)
> выполнена тоже через утилиту sandcl, так что по-прежнему остается
> единственная точка входа в хранилище.
> 
> Для добавления исходников пакета используется команда addsources
> утилиты sandcl:
> 
> 	sandcl addsources имя_пакета исходники
> 
> При выполнении этой команды переданные исходники помещаются на верхний
> уровень хранилища для соответствующего пакета. В момент изменения
> spec-файла в SCM происходит вызов sandcl с параметрами проверки
> корректности новой версии spec-файла и изменения состояния хранилища в
> случае успешности проверки. Выглядит это следующим образом:
> 
> 1) валидируются значения Serial, Name, Version, Release, Group,
>   changelog;
> 
> 2) выясняется, содержит ли предлагаемый к commit'у spec измененные SVR
>   относительно последней ревизии в CVS, при увеличенных происходит
>   простановка cvs tag вида $branch-$serial-$version-$release на
>   последнюю ревизию spec в CVS, ситуация с уменьшенными значениями
>   расценивается как ошибочная. Дополнительно происходит блокировка
>   создания тегов указанного вида напрямую пользователем;
> 
> 3) для каждого указанного в spec файла исходников производятся
>   следующие действия:
> 
>   3.1) проверяется его наличие в корневой для этого пакета ($sources/$name)
>        директории;
> 
>   3.2) если таковой находится, он переносятся на 3 уровня
>        (serial/version/release) ниже;
> 
>   3.3) иначе, проверяется его наличие в name/serial/version/release);
> 
>   3.4) иначе, проверяется его наличие в name/serial/version/*;
> 
>   3.5) иначе, проверяется его наличие в name/serial/*/*;
> 
>   3.6) иначе ситуация считается ошибочной;
> 	
> По возникновению любой из ошибочных ситуаций commit отвергается,
> директория $sources/$name очищается.
> 
> Обратите внимание, что хранение для каждого пакета в SCM только
> spec-файла также делает ненужной со стороны SCM поддержку changesets,
> то есть отслеживания групповых изменений файлов, поскольку каждому
> пакету принадлежит только один файл в SCM -- его spec-файл.
> 
> Состояние SCM в результате выглядит примерно так:
> $ cvs stat -v ruby
> ===================================================================
> File: ruby              Status: Up-to-date
> 
>    Working revision:    1.87
>    Repository revision: 1.87    /data/cvs/alt/packages/ruby,v
>    Sticky Tag:          (none)
>    Sticky Date:         (none)
>    Sticky Options:      (none)
> 
>    Existing Tags:
>         head-0-1_8-alt6                 (revision: 1.86)
>         head-0-1_8-alt5                 (revision: 1.85)
>         head-0-1_8-alt4                 (revision: 1.82)
>         head-0-1_8-alt3                 (revision: 1.79)
>         head-0-1_8-alt2                 (revision: 1.75)
>         head-0-1_7_3-alt7               (revision: 1.50)
>         head-0-1_7_3-alt4               (revision: 1.33)
>         head-0-1_7_3-alt3               (revision: 1.29)
>         head-0-1_7_3-alt2               (revision: 1.28)
>         head-0-1_7_3-alt1               (revision: 1.21)
>         head-0-1_7_2-alt1               (revision: 1.19)
>         head-0-1_6_7-alt1               (revision: 1.4)
>         head-0-1_6_6-alt3               (revision: 1.1)
> 
> Более дружелюбную информацию с точки зрения хранилища можно получить
> командой sandcl queryver, которая возвращает список имеющихся в
> репозитарии версий указанного пакета или группы пакетов:
> 
> $ sandcl queryver ruby
> ruby: 0-1.8-alt2 0-1.8-alt3 0-1.8-alt4 0-1.8-alt5 0-1.8-alt6 0-1.8-alt6
> 
> Получить исходники пакета можно командой sandcl getsources:
> 
> 	 sandcl getsources [опции] имя_пакета [шаблон]
> 
> где в качестве опций может фигурировать опция 
> 
>         -pkgver версия
> 
> позволяющая указать нужную версию пакета согласно нотации, выводимой
> командой sandcl queryver (S-V-R). Указание шаблона позволяет получить
> не все исходники, а только те, которые совпадают с указанным шаблоном.
> 
> Таким образом, можно сделать несколько выводов:
> 
> 1) Хранилище может быть организовано даже с использованием
>    несовершенных в некоторых отношениях свободных SCM, таких как
>    CVS. От SCM требуется только наличие механизма запуска внешних
>    программ при выполнении операций изменения spec-файлов, а так же
>    возможность хранения помеченных состояний файлов (тегов).
> 
> 2) Многоуровневая древовидная система хранения версий пакетов не
>    накладывает ограничений на будущую реализацию хранилища, проста в
>    реализации и в принципе может быть распределенной при использовании
>    в качестве файлового хранилища распределенной файловой системы типа
>    OpenAFS.
> 
> 3) Реализация хранилища на базе Sandman не привязана к конкретной SCM,
>    напротив, интеграция с любой SCM тривиальна.

Для справки:
на этом примерно заканчивается перечень обсуждённых и согласованных
вопросов на LF-5.0

> Предлагаемое решение для ALT Linux Sisyphus.
> 
> Sandman может быть использован для организации версионированного
> хранилища для ALT Linux Sisyphus следующим образом:
> 
> 1) Любой пакет, приходящий в ALT Linux Sisyphus, после пересборки
>    автоматически помещается в sandman:
>   
> 	rpmcpio foo-1.2.3-alt1.src.rpm | sandcl addsources foo
> 
> 	commitlog=$(rpmquery --lastchange -p foo-1.2.3-alt1.src.rpm)
> 
> 	cvs commit -m "$commitlog" foo
> 
> 	где foo в последней строке -- spec-файл пакета foo. 
> 
>    Sandman принципиально требует того, чтобы в SCM имя spec-файла
>    пакета совпадало с именем пакета -- это тот минимум, который
>    требуется для обеспечения непротиворечивости хранилища. 
> 
>    Согласитесь, что, например, иметь пакет openldap и spec-файл для
>    него под именем openldap-2.1.21.spec несколько неосмысленно -- как
>    должен будет называться spec-файл в случае увеличения версии
>    пакета?
> 
>    Отбрасывание расширения .spec также необходимо для упрощения логики
>    реализации хранилища.

Это ограничение несовместимо с нынешним Сизифом.
Я считаю такое сильное ограничение неприемлемым.
Я готов согласиться с ограничением
"имя spec-файла должно иметь вид <имя пакета>.spec"

> 2) Любой разработчик ALT Linux Team получает доступ к sandman для
>    выполнения следующих запросов:
> 
> 	      sandcl querynames
> 	      sandcl queryver
> 	      sandcl query
> 	      sandcl getsources
>    
>    Все эти команды позволяют общаться с хранилищем в режиме "только
>    для чтения". Из нерассмотренных выше, команда sandcl querynames
>    выводит список имеющихся в хранилище пакетов, а sandcl query
>    позвращает граф-описание зависимостей указанного пакета в формате
>    GraphViz dot.

Всё-таки без поддержки полноценных diff'ов usability сужается, особенно
для пользователей с тонким каналом.

> 3) Любой разработчик ALT Linux Team получает доступ по чтению к
>    CVS-модулю, в котором хранятся spec-файлы пакетов.
> 
> 4) Каждый выпущенный дистрибутив помещается в хранилище с
>    использованием возможностей sandman по ведению множественных
>    репозитариев, при этом spec-файлы соответствующих пакетов
>    помещаются в тот же модуль, но в ветку с именем дистрибутива и его
>    версией, например, master_2_2.
> 
> 5) Все обновления в безопасности для уже выпущенных дистрибутивов
>    автоматически помещаются в sandman в соответствующий
>    репозитарий-ветку. Таким образом, для выпущенных дистрибутивов
>    имеется всегда актуальное состояние репозитария и сохраняется
>    история изменений. В частности, это позволит несколько ослабить
>    требование несобирания новых версий в updates, поскольку контроль
>    как зависимостей, так и версий будет значительно проще.

Необходимо также узнать, какие ресурсы требуются для установки sandman'а в
описанном выше виде (можно offlist).

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


-- 
ldv

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

Re: [devel] sandman на cvs.altlinux.org

[Dmitry V. Levin]

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

On Tue, Aug 05, 2003 at 04:23:11PM +0400, Alexey I. Froloff wrote:
> > >>Сборку все-таки лучше через hasher проводить.
> > >Чем лучше?
> > Тем, что incoming разгребается hasher'ом .
> Нет, а чем это лучше, чем родной sandman'овский пересборщик?

Он слишком сильно доверяет собираемым пакетам.

C помощью исходных пакетов специального вида потенциальный
злоумышленник, имеющий доступ к сборочному механизму sandman'а, может
получить права root'а в host-системе.

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

По этой причине для обработки incoming'а sandman использовать нельзя.


-- 
ldv

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

Re: [devel] sandman на cvs.altlinux.org

[Alexander Bokovoy]

On Tue, Aug 05, 2003 at 09:33:26PM +0400, Dmitry V. Levin wrote:
> > 3) Возможность получения любой из хранящихся версий пакета с
> >    максимальным уровнем грануляции (пакет целиком, некоторый набор
> >    исходных файлов, spec-файл).
> 
> Пользователи также хотят иметь возможность получения diff'а между версиями
> (пакета целиком, некоторого набора исходных файлов, spec-файла).
Это в будущем, я специально об этом не упоминал с точки зрения
разработчиков.

> > осмысленным использовать некоторую внешнию схему версионирования
> > бинарных объектов в пакетах RPM, управляемую посредством
> > контролируемых в SCM текстовых объектов пакета. Если обратиться к
> > содержимому любого исходного пакета RPM, то можно увидеть, что только
> > один текстовый объект в нем представляет достаточно информации для
> > контроля всех остальных -- текстовых и бинарных -- объектов пакета и
> > этим контролирующим объектом является spec-файл.
> 
> Это не всегда так.
> Зачастую среди множества исходных файлов данного пакета есть и вполне
> плоские текстовые файлы.
Увы, формализовать структуру для них в общем случае нельзя. Также,
ведение их в SCM требует наличия функциональности changesets, что
неосуществимо для CVS, хотя и есть в Subversion/Aegis, которые обладают
другими существенными недостатками.

> >    Согласитесь, что, например, иметь пакет openldap и spec-файл для
> >    него под именем openldap-2.1.21.spec несколько неосмысленно -- как
> >    должен будет называться spec-файл в случае увеличения версии
> >    пакета?
> > 
> >    Отбрасывание расширения .spec также необходимо для упрощения логики
> >    реализации хранилища.
> 
> Это ограничение несовместимо с нынешним Сизифом.
В каком месте? При сборке Sandman формирование src.rpm и бинарных пакетов
происходит автоматически, Sandman сам добавляет .spec при копировании
spec-файла в build chroot.

При использовании hasher в любом случае предполагается первичная генерация
src.rpm посредством промежуточного скрипта, который может сделать все ту
же работу по приклеиванию .spec. Не вижу, каким образом это несовместимо с
нынешним Сизифом.

> >    Все эти команды позволяют общаться с хранилищем в режиме "только
> >    для чтения". Из нерассмотренных выше, команда sandcl querynames
> >    выводит список имеющихся в хранилище пакетов, а sandcl query
> >    позвращает граф-описание зависимостей указанного пакета в формате
> >    GraphViz dot.
> 
> Всё-таки без поддержки полноценных diff'ов usability сужается, особенно
> для пользователей с тонким каналом.
Diff относительно чего? Двух конкретных версий одного и того же исходника
(если тот определяется как text/plain по мнению file)? Это легко
добавляется, никаких проблем.

> >    имеется всегда актуальное состояние репозитария и сохраняется
> >    история изменений. В частности, это позволит несколько ослабить
> >    требование несобирания новых версий в updates, поскольку контроль
> >    как зависимостей, так и версий будет значительно проще.
> 
> Необходимо также узнать, какие ресурсы требуются для установки sandman'а в
> описанном выше виде (можно offlist).
Вычислительные ресурсы: минимум, если не используется сборка

Дисковый ресурс: однократно -- развернутый Сизиф в исходниках (3.3Гб),
далее -- по нарастающей, плюс место для референтной системы, на которой
вычисляется корректность spec-файла (150-500Мб). Думаю, что 40-60Гб диска
нам хватит надолго, поскольку наиболее дискоемкая функциональность
sandman-а (генерация ISO-образов дистрибутивов) не используется.

-- 
/ Alexander Bokovoy
---
the curls in your keyboard cord are losing electricity.

Re: [devel] sandman на cvs.altlinux.org

[Sergey Bolshakov]

>>>>> "Dmitry" == Dmitry V Levin <ldv@altlinux.org> writes:

 > On Tue, Aug 05, 2003 at 04:23:11PM +0400, Alexey I. Froloff wrote:
 >> > >>Сборку все-таки лучше через hasher проводить.
 >> > >Чем лучше?
 >> > Тем, что incoming разгребается hasher'ом .
 >> Нет, а чем это лучше, чем родной sandman'овский пересборщик?

 > Он слишком сильно доверяет собираемым пакетам.

 > C помощью исходных пакетов специального вида потенциальный
 > злоумышленник, имеющий доступ к сборочному механизму sandman'а, может
 > получить права root'а в host-системе.

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

 > По этой причине для обработки incoming'а sandman использовать нельзя.

Позволю себе небольшое уточнение:
sandman не использует установку src.rpm нигде и никак, эскалация
прав возможна при условии, что на момент сборки в репозитарии
уже существует некий _бинарный_ пакет с 'закладкой'.
 
-- 

Re: [devel] sandman на cvs.altlinux.org

[Dmitry V. Levin]

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

On Tue, Aug 05, 2003 at 08:49:38PM +0300, Alexander Bokovoy wrote:
> On Tue, Aug 05, 2003 at 09:33:26PM +0400, Dmitry V. Levin wrote:
> > > 3) Возможность получения любой из хранящихся версий пакета с
> > >    максимальным уровнем грануляции (пакет целиком, некоторый набор
> > >    исходных файлов, spec-файл).
> > 
> > Пользователи также хотят иметь возможность получения diff'а между версиями
> > (пакета целиком, некоторого набора исходных файлов, spec-файла).
> Это в будущем, я специально об этом не упоминал с точки зрения
> разработчиков.

С этим можно согласиться.

> > > осмысленным использовать некоторую внешнию схему версионирования
> > > бинарных объектов в пакетах RPM, управляемую посредством
> > > контролируемых в SCM текстовых объектов пакета. Если обратиться к
> > > содержимому любого исходного пакета RPM, то можно увидеть, что только
> > > один текстовый объект в нем представляет достаточно информации для
> > > контроля всех остальных -- текстовых и бинарных -- объектов пакета и
> > > этим контролирующим объектом является spec-файл.
> > 
> > Это не всегда так.
> > Зачастую среди множества исходных файлов данного пакета есть и вполне
> > плоские текстовые файлы.
> Увы, формализовать структуру для них в общем случае нельзя. Также,

Почему?

> ведение их в SCM требует наличия функциональности changesets, что
> неосуществимо для CVS, хотя и есть в Subversion/Aegis, которые обладают
> другими существенными недостатками.

Это правда.

> > >    Согласитесь, что, например, иметь пакет openldap и spec-файл для
> > >    него под именем openldap-2.1.21.spec несколько неосмысленно -- как
> > >    должен будет называться spec-файл в случае увеличения версии
> > >    пакета?
> > > 
> > >    Отбрасывание расширения .spec также необходимо для упрощения логики
> > >    реализации хранилища.
> > 
> > Это ограничение несовместимо с нынешним Сизифом.
> В каком месте? При сборке Sandman формирование src.rpm и бинарных пакетов
> происходит автоматически, Sandman сам добавляет .spec при копировании
> spec-файла в build chroot.
> 
> При использовании hasher в любом случае предполагается первичная генерация
> src.rpm посредством промежуточного скрипта, который может сделать все ту
> же работу по приклеиванию .spec. Не вижу, каким образом это несовместимо с
> нынешним Сизифом.

В нем имена spec-файлов имеет вид, отличный от используемого sandman'ом.
Кто будет конвертировать?

Для hasher'а вид имени spec-файла роли не играет.

> > >    Все эти команды позволяют общаться с хранилищем в режиме "только
> > >    для чтения". Из нерассмотренных выше, команда sandcl querynames
> > >    выводит список имеющихся в хранилище пакетов, а sandcl query
> > >    позвращает граф-описание зависимостей указанного пакета в формате
> > >    GraphViz dot.
> > 
> > Всё-таки без поддержки полноценных diff'ов usability сужается, особенно
> > для пользователей с тонким каналом.
> Diff относительно чего? Двух конкретных версий одного и того же исходника
> (если тот определяется как text/plain по мнению file)? Это легко
> добавляется, никаких проблем.

Нет, xdelta на несжатые tarball'ы.
Можно, конечно, отложить на потом.

> > >    имеется всегда актуальное состояние репозитария и сохраняется
> > >    история изменений. В частности, это позволит несколько ослабить
> > >    требование несобирания новых версий в updates, поскольку контроль
> > >    как зависимостей, так и версий будет значительно проще.
> > 
> > Необходимо также узнать, какие ресурсы требуются для установки sandman'а в
> > описанном выше виде (можно offlist).
> Вычислительные ресурсы: минимум, если не используется сборка
> 
> Дисковый ресурс: однократно -- развернутый Сизиф в исходниках (3.3Гб),
> далее -- по нарастающей, плюс место для референтной системы, на которой
> вычисляется корректность spec-файла (150-500Мб). Думаю, что 40-60Гб диска
> нам хватит надолго, поскольку наиболее дискоемкая функциональность
> sandman-а (генерация ISO-образов дистрибутивов) не используется.

А по софту?


-- 
ldv

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

Re: [devel] sandman на cvs.altlinux.org

[Dmitry V. Levin]

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

On Tue, Aug 05, 2003 at 08:56:50PM +0300, Sergey Bolshakov wrote:
>  >> > >>Сборку все-таки лучше через hasher проводить.
>  >> > >Чем лучше?
>  >> > Тем, что incoming разгребается hasher'ом .
>  >> Нет, а чем это лучше, чем родной sandman'овский пересборщик?
> 
>  > Он слишком сильно доверяет собираемым пакетам.
> 
>  > C помощью исходных пакетов специального вида потенциальный
>  > злоумышленник, имеющий доступ к сборочному механизму sandman'а, может
>  > получить права root'а в host-системе.
> 
>  > Это не ошибка реализации, это выбор архитектора, который предназначал
>  > sandman для решения других задач (тех, которые в своём письме описал
>  > Саша).
> 
>  > По этой причине для обработки incoming'а sandman использовать нельзя.
> 
> Позволю себе небольшое уточнение:
> sandman не использует установку src.rpm нигде и никак, эскалация
> прав возможна при условии, что на момент сборки в репозитарии
> уже существует некий _бинарный_ пакет с 'закладкой'.

Разумеется, но и этого достаточно.
Причём репозитарием с 'закладкой' может быть даже не Sisyphus, а
вспомогательный, который необходим для последовательной сборки нескольких
пакетов.


-- 
ldv

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

Re: [devel] sandman на cvs.altlinux.org

[Alexander Bokovoy]

On Tue, Aug 05, 2003 at 09:58:22PM +0400, Dmitry V. Levin wrote:
> > > > контроля всех остальных -- текстовых и бинарных -- объектов пакета и
> > > > этим контролирующим объектом является spec-файл.
> > > 
> > > Это не всегда так.
> > > Зачастую среди множества исходных файлов данного пакета есть и вполне
> > > плоские текстовые файлы.
> > Увы, формализовать структуру для них в общем случае нельзя. Также,
> Почему?
Придется делать это по-пакетно. Вот эти файлы -- текстовые, а эти -- нет.
И так далее. То есть, кто-то должен проанализировать пакет и разложить его
исходники в хранилище и в SCM, да еще и учесть возможность удаления
исходников из SCM -- этот вариант наиболее непригляден.

> > При использовании hasher в любом случае предполагается первичная генерация
> > src.rpm посредством промежуточного скрипта, который может сделать все ту
> > же работу по приклеиванию .spec. Не вижу, каким образом это несовместимо с
> > нынешним Сизифом.
> 
> В нем имена spec-файлов имеет вид, отличный от используемого sandman'ом.
> Кто будет конвертировать?
Давай разделим проблемы. От пакетов, попадающих в Sisyphus, требуется
наличие в них регуляризованных spec-файлов в формате foo.spec. Для Sandman
даже это не существенно, так как перед попаданием содержимого исходного
пакета в хранилище (суть, вызов команд утилиты sandcl) этот src.rpm будет
раскручиваться, например, так:

addpackage() {
    name=$($RPMQ --qf='%{NAME}' -p $1)
    basepart=$(basename $1)
    echo -e "\tImporting sources into Sandman..."
    $RPM2CPIO $1 | $SANDCL addsources $name
    pushd $CVSDIR
    $RPM2CPIO $1 | $CPIO -i $name.spec
    if [ ! -f $name ] ; then
        mv -f $name.spec $name
	echo -e "\tAdding spec file to CVS..."
	cvs add $name
    else
	mv $name.spec $name
    fi
    echo -e "\tImporting package ${basepart/.src.rpm/} ..."
    cvs ci -m "Imported package ${basepart/.src.rpm/}" $name
    popd
}

Как видишь, в данном случае мы предполагаем, что spec-файл называется
имя_пакета.spec в src.rpm. Вот и все. Напишем скрипт, который будет
выуживать любой spec-файл, -- не будет и этого ограничения.

> > Diff относительно чего? Двух конкретных версий одного и того же исходника
> > (если тот определяется как text/plain по мнению file)? Это легко
> > добавляется, никаких проблем.
> 
> Нет, xdelta на несжатые tarball'ы.
> Можно, конечно, отложить на потом.
Угу. Кстати, это дополнительная вычислительная нагрузка.

> > Вычислительные ресурсы: минимум, если не используется сборка
> > 
> > Дисковый ресурс: однократно -- развернутый Сизиф в исходниках (3.3Гб),
> > далее -- по нарастающей, плюс место для референтной системы, на которой
> > вычисляется корректность spec-файла (150-500Мб). Думаю, что 40-60Гб диска
> > нам хватит надолго, поскольку наиболее дискоемкая функциональность
> > sandman-а (генерация ISO-образов дистрибутивов) не используется.
> 
> А по софту?
Смотри зависимости пакета sandman-server:

$ apt-cache depends sandman-server:

sandman-server-0.5.5-alt4
  Для установки требует: cvs
  Требует: sandman = 0.5.5-alt4
  Требует: apt-utils
  Требует: chrootuid >= 1.3-alt2
  Требует: e2fsprogs
  Требует: mount
  Требует: apt >= 0.5.5cnc4.1-alt4
  Требует: service >= 0.4-alt1
  Требует: sh-2.05b-alt5
  Требует: logrotate-3.6.2-alt2
  Требует: service-0.5-alt1

$ apt-cache depends sandman

sandman-0.5.5-alt4
  Требует: cpio
  Требует: tcl >= 8.4.2-alt1
  Требует: tclx
  Требует: tcllib >= 0.8
  Требует: tcl-trf
  Требует: tcl-memchan

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

-- 
/ Alexander Bokovoy
---
The clearest way into the Universe is through a forest wilderness.
		-- John Muir

[devel] Re: sandman на cvs.altlinux.org

[Alexey Tourbin]

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

On Tue, Aug 05, 2003 at 08:49:38PM +0300, Alexander Bokovoy wrote:
> > Это ограничение несовместимо с нынешним Сизифом.
> В каком месте? При сборке Sandman формирование src.rpm и бинарных пакетов
> происходит автоматически, Sandman сам добавляет .spec при копировании
> spec-файла в build chroot.

perl58.spec

Я не хотел бы переименовывать spec-файл, т.к. perl.spec ассоциируется у
меня с perl56.spec, а при выходе perl-5.10.0 будет создан perl510.spec.
Иными словами, это достататочно независимые спеки, которые интенсивно
используются и развиваются в течение ~3 лет.  Поэтому мне удобно иметь
разные файлы/имена.

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

Re: [devel] sandman на cvs.altlinux.org

[Sergey Bolshakov]

>>>>> "Dmitry" == Dmitry V Levin <ldv@altlinux.org> writes:
[skipped]
 >> > C помощью исходных пакетов специального вида потенциальный
 >> > злоумышленник, имеющий доступ к сборочному механизму sandman'а, может
 >> > получить права root'а в host-системе.
 >> 
 >> > Это не ошибка реализации, это выбор архитектора, который предназначал
 >> > sandman для решения других задач (тех, которые в своём письме описал
 >> > Саша).
 >> 
 >> > По этой причине для обработки incoming'а sandman использовать нельзя.
 >> 
 >> Позволю себе небольшое уточнение:
 >> sandman не использует установку src.rpm нигде и никак, эскалация
 >> прав возможна при условии, что на момент сборки в репозитарии
 >> уже существует некий _бинарный_ пакет с 'закладкой'.

 > Разумеется, но и этого достаточно.
 > Причём репозитарием с 'закладкой' может быть даже не Sisyphus, а
 > вспомогательный, который необходим для последовательной сборки нескольких
 > пакетов.

Что, в свою очередь, приводит к мысли о уместности добавления
к имеющимся проверкам на заключительной стадии сборки пакета
rpm'ом некоего валидатора %pre/post и т.д. скриптов :)

-- 

Re: [devel] sandman на cvs.altlinux.org

[Dmitry V. Levin]

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

On Tue, Aug 05, 2003 at 09:13:10PM +0300, Sergey Bolshakov wrote:
>  >> > C помощью исходных пакетов специального вида потенциальный
>  >> > злоумышленник, имеющий доступ к сборочному механизму sandman'а, может
>  >> > получить права root'а в host-системе.
>  >> 
>  >> > Это не ошибка реализации, это выбор архитектора, который предназначал
>  >> > sandman для решения других задач (тех, которые в своём письме описал
>  >> > Саша).
>  >> 
>  >> > По этой причине для обработки incoming'а sandman использовать нельзя.
>  >> 
>  >> Позволю себе небольшое уточнение:
>  >> sandman не использует установку src.rpm нигде и никак, эскалация
>  >> прав возможна при условии, что на момент сборки в репозитарии
>  >> уже существует некий _бинарный_ пакет с 'закладкой'.
> 
>  > Разумеется, но и этого достаточно.
>  > Причём репозитарием с 'закладкой' может быть даже не Sisyphus, а
>  > вспомогательный, который необходим для последовательной сборки нескольких
>  > пакетов.
> 
> Что, в свою очередь, приводит к мысли о уместности добавления
> к имеющимся проверкам на заключительной стадии сборки пакета
> rpm'ом некоего валидатора %pre/post и т.д. скриптов :)

На который все равно нельзя будет положиться на 100%,
что не отменяет потребность в нем.


-- 
ldv

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

Re: [devel] Re: sandman на cvs.altlinux.org

[Alexander Bokovoy]

On Tue, Aug 05, 2003 at 10:12:35PM +0400, Alexey Tourbin wrote:
> On Tue, Aug 05, 2003 at 08:49:38PM +0300, Alexander Bokovoy wrote:
> > > Это ограничение несовместимо с нынешним Сизифом.
> > В каком месте? При сборке Sandman формирование src.rpm и бинарных пакетов
> > происходит автоматически, Sandman сам добавляет .spec при копировании
> > spec-файла в build chroot.
> 
> perl58.spec
> 
> Я не хотел бы переименовывать spec-файл, т.к. perl.spec ассоциируется у
> меня с perl56.spec, а при выходе perl-5.10.0 будет создан perl510.spec.
> Иными словами, это достататочно независимые спеки, которые интенсивно
> используются и развиваются в течение ~3 лет.  Поэтому мне удобно иметь
> разные файлы/имена.
Они все в одном пакете?

-- 
/ Alexander Bokovoy
---
You should emulate your heros, but don't carry it too far.  Especially
if they are dead.

Re: [devel] Re: sandman на cvs.altlinux.org

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Tourbin <at@altlinux.ru> writes:
 > Я не хотел бы переименовывать spec-файл, т.к. perl.spec ассоциируется у
 > меня с perl56.spec, а при выходе perl-5.10.0 будет создан perl510.spec.
 > Иными словами, это достататочно независимые спеки, которые интенсивно
 > используются и развиваются в течение ~3 лет.  Поэтому мне удобно иметь
 > разные файлы/имена.

Собственно, для преодоления подобных неудобств и был придуман CVS :)

-- 

Re: [devel] sandman на cvs.altlinux.org

[Dmitry V. Levin]

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

On Tue, Aug 05, 2003 at 09:09:55PM +0300, Alexander Bokovoy wrote:
> On Tue, Aug 05, 2003 at 09:58:22PM +0400, Dmitry V. Levin wrote:
> > > > > контроля всех остальных -- текстовых и бинарных -- объектов пакета и
> > > > > этим контролирующим объектом является spec-файл.
> > > > 
> > > > Это не всегда так.
> > > > Зачастую среди множества исходных файлов данного пакета есть и вполне
> > > > плоские текстовые файлы.
> > > Увы, формализовать структуру для них в общем случае нельзя. Также,
> > Почему?
> Придется делать это по-пакетно. Вот эти файлы -- текстовые, а эти -- нет.
> И так далее. То есть, кто-то должен проанализировать пакет и разложить его
> исходники в хранилище и в SCM, да еще и учесть возможность удаления
> исходников из SCM -- этот вариант наиболее непригляден.

Однако он решает эту задачу (правда, при этом возникает проблема
гранулярности изменений).

> > > При использовании hasher в любом случае предполагается первичная генерация
> > > src.rpm посредством промежуточного скрипта, который может сделать все ту
> > > же работу по приклеиванию .spec. Не вижу, каким образом это несовместимо с
> > > нынешним Сизифом.
> > 
> > В нем имена spec-файлов имеет вид, отличный от используемого sandman'ом.
> > Кто будет конвертировать?
> Давай разделим проблемы. От пакетов, попадающих в Sisyphus, требуется
> наличие в них регуляризованных spec-файлов в формате foo.spec. Для Sandman
> даже это не существенно [...]

Это уже хорошо.
А perl58.spec оно съест?

> > А по софту?
> Смотри зависимости пакета sandman-server:
> 
> $ apt-cache depends sandman-server:
> 
> sandman-server-0.5.5-alt4
>   Для установки требует: cvs
>   Требует: sandman = 0.5.5-alt4
>   Требует: apt-utils
>   Требует: chrootuid >= 1.3-alt2
>   Требует: e2fsprogs
>   Требует: mount
>   Требует: apt >= 0.5.5cnc4.1-alt4
>   Требует: service >= 0.4-alt1
>   Требует: sh-2.05b-alt5
>   Требует: logrotate-3.6.2-alt2
>   Требует: service-0.5-alt1

Какие из них действительно нужны для "усечённого" sandman'а?

Их вышеприведённого мне не нравится:
chrootuid
e2fsprogs
mount
service
logrotate


-- 
ldv

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

Re: [devel] sandman на cvs.altlinux.org

[Sergey Bolshakov]

>>>>> "Dmitry" == Dmitry V Levin <ldv@altlinux.org> writes:
[skipped]
 >> > А по софту?
 >> Смотри зависимости пакета sandman-server:
 >> 
 >> $ apt-cache depends sandman-server:
 >> 
 >> sandman-server-0.5.5-alt4
 >> Для установки требует: cvs
 >> Требует: sandman = 0.5.5-alt4
 >> Требует: apt-utils
 >> Требует: chrootuid >= 1.3-alt2
 >> Требует: e2fsprogs
 >> Требует: mount
 >> Требует: apt >= 0.5.5cnc4.1-alt4
 >> Требует: service >= 0.4-alt1
 >> Требует: sh-2.05b-alt5
 >> Требует: logrotate-3.6.2-alt2
 >> Требует: service-0.5-alt1

 > Какие из них действительно нужны для "усечённого" sandman'а?

 > Их вышеприведённого мне не нравится:
 > chrootuid
 > e2fsprogs
 > mount
 > service
 > logrotate

Краткий ответ: все, хотя бы потому, что 'усеченного' sandman
просто не существует.

Развернутый:
Начнем с того, что для корректной обработки предлагаемого к коммиту
spec-файла (в т.ч. и определения списка исходников/патчей) необходима
среда, соответствующая репозитарию, host-система не годится по определению.
Таким образом, всегда существует ненулевое количество 'ссылочных' или
'образцовых' чрутов, достаточных для запуска rpm -bE. Создание
такого чрута ничем не отличается от создания чрута для собственно
сборки, разве что список пакетов более-менее известен и 'карманные'
репозитарии в рассчет не принимаются. Таким образом, 'усеченный'
sandman в некотором смысле ничем не отличается от полного.

Я готов уделить некоторое время интеграции в sandman fakeroot,
(это, насколько я понимаю, существенно снизит риски ?), если
это позволит надеяться на развитие sandman не только в роли
архивариуса. 

-- 

Re: [devel] sandman на cvs.altlinux.org

[Anton Farygin]

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

Dmitry V. Levin пишет:
> On Tue, Aug 05, 2003 at 08:49:38PM +0300, Alexander Bokovoy wrote:
> 
>>On Tue, Aug 05, 2003 at 09:33:26PM +0400, Dmitry V. Levin wrote:
>>
>>>>3) Возможность получения любой из хранящихся версий пакета с
>>>>   максимальным уровнем грануляции (пакет целиком, некоторый набор
>>>>   исходных файлов, spec-файл).
>>>
>>>Пользователи также хотят иметь возможность получения diff'а между версиями
>>>(пакета целиком, некоторого набора исходных файлов, spec-файла).
>>
>>Это в будущем, я специально об этом не упоминал с точки зрения
>>разработчиков.
> 
> 
> С этим можно согласиться.
> 
> 
>>>>осмысленным использовать некоторую внешнию схему версионирования
>>>>бинарных объектов в пакетах RPM, управляемую посредством
>>>>контролируемых в SCM текстовых объектов пакета. Если обратиться к
>>>>содержимому любого исходного пакета RPM, то можно увидеть, что только
>>>>один текстовый объект в нем представляет достаточно информации для
>>>>контроля всех остальных -- текстовых и бинарных -- объектов пакета и
>>>>этим контролирующим объектом является spec-файл.
>>>
>>>Это не всегда так.
>>>Зачастую среди множества исходных файлов данного пакета есть и вполне
>>>плоские текстовые файлы.
>>
>>Увы, формализовать структуру для них в общем случае нельзя. Также,
> 
> 
> Почему?
> 
> 
>>ведение их в SCM требует наличия функциональности changesets, что
>>неосуществимо для CVS, хотя и есть в Subversion/Aegis, которые обладают
>>другими существенными недостатками.
> 
> 
> Это правда.
> 
> 
>>>>   Согласитесь, что, например, иметь пакет openldap и spec-файл для
>>>>   него под именем openldap-2.1.21.spec несколько неосмысленно -- как
>>>>   должен будет называться spec-файл в случае увеличения версии
>>>>   пакета?
>>>>
>>>>   Отбрасывание расширения .spec также необходимо для упрощения логики
>>>>   реализации хранилища.
>>>
>>>Это ограничение несовместимо с нынешним Сизифом.
>>
>>В каком месте? При сборке Sandman формирование src.rpm и бинарных пакетов
>>происходит автоматически, Sandman сам добавляет .spec при копировании
>>spec-файла в build chroot.
>>
>>При использовании hasher в любом случае предполагается первичная генерация
>>src.rpm посредством промежуточного скрипта, который может сделать все ту
>>же работу по приклеиванию .spec. Не вижу, каким образом это несовместимо с
>>нынешним Сизифом.
> 
> 
> В нем имена spec-файлов имеет вид, отличный от используемого sandman'ом.
> Кто будет конвертировать?
> 
> Для hasher'а вид имени spec-файла роли не играет.

Дим, я вчера наваял совсем простенький скрипт, конвертирующий kernel CVS 
в sandman репозитарий (для коммита).

В принципе - конверталку мы напишем. Но могу сказать одно - работать с 
такими файлами неудобно - дисковые операции поиска спеков значительно 
замедляются (приходится еще анализировать содержимое каждого файла).

Я бы рекомендовал разработчикам Sandman внести в него изменения, которые 
позволят держать в репозитарии спеки с более человеческим именем (+.spec)

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

rpm -q --queryformat='%{NAME}\n' --specfile <имя спек-файла>

вернет вам имя вашего спека.

Rgds,
Rider

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

Re: [devel] sandman на cvs.altlinux.org

[Dmitry V. Levin]

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

On Wed, Aug 06, 2003 at 11:46:16AM +0400, Anton Farygin wrote:
> Ну а если быть более честным, то имя спек-файла не имеет никакого 
> значения, ибо одна тривиальная операция:
> 
> rpm -q --queryformat='%{NAME}\n' --specfile <имя спек-файла>
> 
> вернет вам имя вашего спека.

Мечтать не вредно, но думать тоже надо:
$ rpm -q --queryformat='%{NAME}\n' --specfile readline.spec 
readline
libreadline
libreadline-devel
libreadline-devel-static
(замечу, что бинарного пакета readline нет)

Кроме того, rpmquery --queryformat нельзя делать в host-системе.


-- 
ldv

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

Re: [devel] sandman на cvs.altlinux.org

[Sergey Bolshakov]

>>>>> "Anton" == Anton Farygin <rider@altlinux.com> writes:
[skipped]
 > Дим, я вчера наваял совсем простенький скрипт, конвертирующий kernel
 > CVS в sandman репозитарий (для коммита).

 > В принципе - конверталку мы напишем. Но могу сказать одно - работать с
 > такими файлами неудобно - дисковые операции поиска спеков значительно
 > замедляются (приходится еще анализировать содержимое каждого файла).

 > Я бы рекомендовал разработчикам Sandman внести в него изменения,
 > которые позволят держать в репозитарии спеки с более человеческим
 > именем (+.spec)

 > Ну а если быть более честным, то имя спек-файла не имеет никакого
 > значения, ибо одна тривиальная операция:

 > rpm -q --queryformat='%{NAME}\n' --specfile <имя спек-файла>

 > вернет вам имя вашего спека.

Вернет, куда ж денется.
Сколько процессора будет сожрано впустую на простой операции
querynames для пары тысяч пакетов ? 
Я нахожу введение дополнительного уровня индирекции только
для удовлетворения каприза произвольно именовать spec-файл
совершенно ненужным.

-- 

Re: [devel] sandman на cvs.altlinux.org

[Michael Shigorin]

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

On Tue, Aug 05, 2003 at 03:35:29PM +0400, Alexey I. Froloff wrote:
> > Сборку все-таки лучше через hasher проводить.
> Чем лучше?

Насколько я понимаю, тем, что написанное rm -rf /* мной в %pre
какого-нибудь пакета, являющегося (рекурсивно) необходимым для
собрки пересобираемого тобой будет выполняться все же с разными
правами.

И все равно есть подозрение, что провелярка собираемости /
собиралка в изоленте и BTE -- вещи достаточно разного калибра,
чтобы вместо правки одного места последнего делать фромскратч в
условиях достаточно ограниченных ресурсов.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

Re: [devel] sandman на cvs.altlinux.org

[Grigory Milev]

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

>>>>> "Michael" == Michael Shigorin <mike@osdn.org.ua> writes:
    Michael> Насколько я понимаю, тем, что написанное rm -rf /* мной в %pre
    Michael> какого-нибудь пакета, являющегося (рекурсивно) необходимым для
    Michael> собрки пересобираемого тобой будет выполняться все же с разными
    Michael> правами.
Это выполнится в chroot'е, что вообще не страшно, опасность вызывает
возможность из pre/post подмонтировать другие диски сборочного сервера и
сделать rm -rf /* там или есче чего-нить нехорошего, например положить ssh-key
в /root/.ssh/authorized_keys2

+--------------------------------------------------------+
Grigory Milev	mailto:week@altlinux.ru
ALT Linux Team	http://www.altlinux.ru
+--------------------------------------------------------+
Life too beautiful and interesting. Don't worry, be happy.

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

Re: [devel] sandman на cvs.altlinux.org

[Dmitry V. Levin]

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

On Tue, Aug 12, 2003 at 05:57:19PM +0300, Grigory Milev wrote:
> >>>>> "Michael" == Michael Shigorin <mike@osdn.org.ua> writes:
>     Michael> Насколько я понимаю, тем, что написанное rm -rf /* мной в %pre
>     Michael> какого-нибудь пакета, являющегося (рекурсивно) необходимым для
>     Michael> собрки пересобираемого тобой будет выполняться все же с разными
>     Michael> правами.
> Это выполнится в chroot'е, что вообще не страшно [...]

С правами root'а под обычным ядром - не просто страшно, а instant death.

Впрочем, мы это вроде бы уже обсудили.


-- 
ldv

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

Re: [devel] sandman на cvs.altlinux.org

[Ivan Zakharyaschev]

	Hello!

On Tue, 5 Aug 2003, Alexander Bokovoy wrote:

> On Mon, Aug 04, 2003 at 12:50:35PM +0300, Alexander Bokovoy
> wrote:

> Итак, опус прикладывается:
> ===============================================================
> ==============

....

> Предлагаемое решение для ALT Linux Sisyphus.
>
> Sandman может быть использован для организации
> версионированного
> хранилища для ALT Linux Sisyphus следующим образом:
>
> 1) Любой пакет, приходящий в ALT Linux Sisyphus, после
> пересборки
>    автоматически помещается в sandman:
>
> 	rpmcpio foo-1.2.3-alt1.src.rpm | sandcl addsources foo
>
> 	commitlog=$(rpmquery --lastchange -p
> foo-1.2.3-alt1.src.rpm)
>
>
> 	cvs commit -m "$commitlog" foo
>
> 	где foo в последней строке -- spec-файл пакета foo.

Возможное усовершенствование: вместо --lastchange использовать
--changes-since <S:V-R последнего релиза в этой ветке>.

Зачем:
Номера официально регистрируемых в Sandman релизов могут по
каким-то причинам идти не непосредственно друг за другом.
Например, некоторые промежуточные релизы могут быть сделаны
только для внутреннего тестирования разработчиком. Или другой
пример: в истории моих пакетов, которую я до сих пор храню сам
как умею, часть релизов утеряно, и если я её захочу перенести в
Sandman, то log-и будут выглядет более осмысленно, если они
действительно будут отражать все изменения между commit-ами.

Может, это будет полезно и для пакетов в ветках updates к
дистрибутивам: там в chnagelog-е может быть много записей между
выпущенными как updates релизами.

--changes-since требует большей строгости в формате chnagelog-а
(нужно чтобы у каждой записи были хотя бы Version-Release).

>
>    Sandman принципиально требует того, чтобы в SCM имя
> spec-файла
>    пакета совпадало с именем пакета -- это тот минимум,
> который
>    требуется для обеспечения непротиворечивости хранилища.
>
>    Согласитесь, что, например, иметь пакет openldap и
> spec-файл для
>    него под именем openldap-2.1.21.spec несколько неосмысленно
> -- как
>    должен будет называться spec-файл в случае увеличения
> версии
>    пакета?
>
>    Отбрасывание расширения .spec также необходимо для
> упрощения логики
>    реализации хранилища.
>
> 2)

....

> 4) Каждый выпущенный дистрибутив помещается в хранилище с
>    использованием возможностей sandman по ведению
> множественных
>    репозитариев, при этом spec-файлы соответствующих пакетов
>    помещаются в тот же модуль, но в ветку с именем
> дистрибутива и его
>    версией, например, master_2_2.
>
> 5) Все обновления в безопасности для уже выпущенных
> дистрибутивов
>    автоматически помещаются в sandman в соответствующий
>    репозитарий-ветку. Таким образом, для выпущенных
> дистрибутивов
>    имеется всегда актуальное состояние репозитария и
> сохраняется
>    история изменений. В частности, это позволит несколько
> ослабить
>    требование несобирания новых версий в updates, поскольку
> контроль
>    как зависимостей, так и версий будет значительно проще.
>
> При появлении отдельного сборочного сервера можно будет
> дополнительно
> разрешить использование сборочных функций Sandman для всех
> поддерживаемых репозитариев.

-- 
С наилучшими пожеланиями,
Иван Захарьящев, Москва
::
JabberID: imz at altlinux.org

Re: [devel] sandman на cvs.altlinux.org

[Alexander Bokovoy]

On Wed, Aug 13, 2003 at 09:05:35PM +0400, Ivan Zakharyaschev wrote:
> >
> > 	rpmcpio foo-1.2.3-alt1.src.rpm | sandcl addsources foo
> >
> > 	commitlog=$(rpmquery --lastchange -p
> > foo-1.2.3-alt1.src.rpm)
> >
> >
> > 	cvs commit -m "$commitlog" foo
> >
> > 	где foo в последней строке -- spec-файл пакета foo.
> 
> Возможное усовершенствование: вместо --lastchange использовать
> --changes-since <S:V-R последнего релиза в этой ветке>.
Согласен. Я это и имел в виду, но неверно выразился.

-- 
/ Alexander Bokovoy
Hello.  I know the divorce rate among unmarried Catholic Alaskan females!!

Re: [devel] sandman на cvs.altlinux.org

[Stanislav Ievlev]

On Mon, Aug 04, 2003 at 12:36:16PM +0400, Anton Farygin wrote:
> Всем привет.
> 
> Господа, вопрос стоит в поднятии sandman на cvs.altlinux.org для 
> хранения развернутого дерева репозитария.
> 
> Саша Боковой утверждает что он договорился об этом с Димой Левиным.
> 
> Соответственно вопрос к Диме: когда планируется поднимать sandman на 
> cvs.altlinux.org ?
> 
> И как в этом случае будет жить hasher? Где будет происходить сборка ?
Прошу прощения, то чем закончилась эта дискуссия?
> 
> Rgds,
> Rider



> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel

Re: [devel] sandman на cvs.altlinux.org

[Anton Farygin]

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

Stanislav Ievlev пишет:
> On Mon, Aug 04, 2003 at 12:36:16PM +0400, Anton Farygin wrote:
> 
>>Всем привет.
>>
>>Господа, вопрос стоит в поднятии sandman на cvs.altlinux.org для 
>>хранения развернутого дерева репозитария.
>>
>>Саша Боковой утверждает что он договорился об этом с Димой Левиным.
>>
>>Соответственно вопрос к Диме: когда планируется поднимать sandman на 
>>cvs.altlinux.org ?
>>
>>И как в этом случае будет жить hasher? Где будет происходить сборка ?
> 
> Прошу прощения, то чем закончилась эта дискуссия?
> 

На данный момент - твоим письмом. Т.е. - ничем. Ибо Дима обещал что-то 
сказать по этому поводу, но так и не сказал.

Rgds,
Rider

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

Re: [devel] sandman на cvs.altlinux.org

[Dmitry V. Levin]

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

On Tue, Aug 05, 2003 at 09:54:14PM +0300, Sergey Bolshakov wrote:
[...]
>  > Какие из них действительно нужны для "усечённого" sandman'а?
> 
>  > Их вышеприведённого мне не нравится:
>  > chrootuid
>  > e2fsprogs
>  > mount
>  > service
>  > logrotate
> 
> Краткий ответ: все, хотя бы потому, что 'усеченного' sandman
> просто не существует.
> 
> Развернутый:
> Начнем с того, что для корректной обработки предлагаемого к коммиту
> spec-файла (в т.ч. и определения списка исходников/патчей) необходима
> среда, соответствующая репозитарию, host-система не годится по определению.
> Таким образом, всегда существует ненулевое количество 'ссылочных' или
> 'образцовых' чрутов, достаточных для запуска rpm -bE. Создание
> такого чрута ничем не отличается от создания чрута для собственно
> сборки, разве что список пакетов более-менее известен и 'карманные'
> репозитарии в рассчет не принимаются. Таким образом, 'усеченный'
> sandman в некотором смысле ничем не отличается от полного.

С одной стороны, не совсем понятно, как определять состав "ссылочной"
сборочной среды.  Как минимум, в ней должны быть все необходимые файлы
из /etc/rpm/macros.d/; как быть, если они вместе не живут, напр.,
linuxpam-devel и openpam-devel?

С другой стороны, создавать такие объекты можно и без столь дорогостоящих
(иногда) средств.

> Я готов уделить некоторое время интеграции в sandman fakeroot,
> (это, насколько я понимаю, существенно снизит риски ?), если

Думаю, что одного fakeroot'а не хватит, нужно как минимум ещё реализовать
аналоги killuid и ipcrm.

> это позволит надеяться на развитие sandman не только в роли
> архивариуса. 

Боюсь, что для всего Сизифа ближайшие несколько лет этого сделать не
удастся.  Проблема в CVS'е и слабых каналах связи.  Master repository
должен находится на достаточно широком и быстром канале, чтобы с ним могло
работать хотя бы большинство разработчиков, у которых также должны быть
соответствующие каналы связи.  А пока их нет, пока даже у нас в офисе
качество связи ниже плинтуса, о таких решениях в рамках Сизифа остаётся
только мечтать.


--
ldv

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

Re: [devel] sandman на cvs.altlinux.org

[Anton Farygin]

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

Dmitry V. Levin пишет:
> On Tue, Aug 05, 2003 at 09:54:14PM +0300, Sergey Bolshakov wrote:
> [...]
> 
>> > Какие из них действительно нужны для "усечённого" sandman'а?
>>
>> > Их вышеприведённого мне не нравится:
>> > chrootuid
>> > e2fsprogs
>> > mount
>> > service
>> > logrotate
>>
>>Краткий ответ: все, хотя бы потому, что 'усеченного' sandman
>>просто не существует.
>>
>>Развернутый:
>>Начнем с того, что для корректной обработки предлагаемого к коммиту
>>spec-файла (в т.ч. и определения списка исходников/патчей) необходима
>>среда, соответствующая репозитарию, host-система не годится по определению.
>>Таким образом, всегда существует ненулевое количество 'ссылочных' или
>>'образцовых' чрутов, достаточных для запуска rpm -bE. Создание
>>такого чрута ничем не отличается от создания чрута для собственно
>>сборки, разве что список пакетов более-менее известен и 'карманные'
>>репозитарии в рассчет не принимаются. Таким образом, 'усеченный'
>>sandman в некотором смысле ничем не отличается от полного.
> 
> 
> С одной стороны, не совсем понятно, как определять состав "ссылочной"
> сборочной среды.  Как минимум, в ней должны быть все необходимые файлы
> из /etc/rpm/macros.d/; как быть, если они вместе не живут, напр.,
> linuxpam-devel и openpam-devel?
> 
> С другой стороны, создавать такие объекты можно и без столь дорогостоящих
> (иногда) средств.
> 
> 
>>Я готов уделить некоторое время интеграции в sandman fakeroot,
>>(это, насколько я понимаю, существенно снизит риски ?), если
> 
> 
> Думаю, что одного fakeroot'а не хватит, нужно как минимум ещё реализовать
> аналоги killuid и ipcrm.
> 
> 
>>это позволит надеяться на развитие sandman не только в роли
>>архивариуса. 
> 
> 
> Боюсь, что для всего Сизифа ближайшие несколько лет этого сделать не
> удастся.  Проблема в CVS'е и слабых каналах связи.  Master repository
> должен находится на достаточно широком и быстром канале, чтобы с ним могло
> работать хотя бы большинство разработчиков, у которых также должны быть
> соответствующие каналы связи.  А пока их нет, пока даже у нас в офисе
> качество связи ниже плинтуса, о таких решениях в рамках Сизифа остаётся
> только мечтать.

Как вариант - разработка собственной системы распределенных 
репозитариев. С репликациями в определенное время суток.

Есть желающие ?

Rgds,
Rider

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

Re: [devel] sandman на cvs.altlinux.org

[Sviatoslav Sviridov]

On Mon, 22 Sep 2003 09:49:56 +0400
Anton Farygin <rider@altlinux.com> wrote:

> <skipped>
> > 
> > Боюсь, что для всего Сизифа ближайшие несколько лет этого сделать не
> > удастся.  Проблема в CVS'е и слабых каналах связи.  Master repository
> > должен находится на достаточно широком и быстром канале, чтобы с ним могло
> > работать хотя бы большинство разработчиков, у которых также должны быть
> > соответствующие каналы связи.  А пока их нет, пока даже у нас в офисе
> > качество связи ниже плинтуса, о таких решениях в рамках Сизифа остаётся
> > только мечтать.
> 
> Как вариант - разработка собственной системы распределенных 
> репозитариев. С репликациями в определенное время суток.
> 
> Есть желающие ?

Ну это, пожалуй, черезчур :)
Лучше уж использовать/развивать что-либо из уже имеющегося... Благо, их есть у
нас :)
Ну вот хотя бы:
http://better-scm.berlios.de/comparison/comparison.html
Более половины из описанных систем умеют реплицироваться :)

-- Sviatoslav Sviridov <svd at lintec dot minsk dot by>
    /* icq: 10845380; jid: svd at altlinux dot org; */

	"What's that thing?"
	"Well, it's a highly technical, sensitive instrument we use in
computer repair.  Being a layman, you probably can't grasp exactly what
it does.  We call it a two-by-four."
		-- Jeff MacNelley, "Shoe"

Re: [devel] sandman на cvs.altlinux.org

[Anton Farygin]

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

Sviatoslav Sviridov пишет:
> On Mon, 22 Sep 2003 09:49:56 +0400
> Anton Farygin <rider@altlinux.com> wrote:
> 
> 
>><skipped>
>>
>>>Боюсь, что для всего Сизифа ближайшие несколько лет этого сделать не
>>>удастся.  Проблема в CVS'е и слабых каналах связи.  Master repository
>>>должен находится на достаточно широком и быстром канале, чтобы с ним могло
>>>работать хотя бы большинство разработчиков, у которых также должны быть
>>>соответствующие каналы связи.  А пока их нет, пока даже у нас в офисе
>>>качество связи ниже плинтуса, о таких решениях в рамках Сизифа остаётся
>>>только мечтать.
>>
>>Как вариант - разработка собственной системы распределенных 
>>репозитариев. С репликациями в определенное время суток.
>>
>>Есть желающие ?
> 
> 
> Ну это, пожалуй, черезчур :)
> Лучше уж использовать/развивать что-либо из уже имеющегося... Благо, их есть у
> нас :)
> Ну вот хотя бы:
> http://better-scm.berlios.de/comparison/comparison.html
> Более половины из описанных систем умеют реплицироваться :)

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

А из этого списка все имеют какие-то недостатки.. например Aegis - SUID, 
Subversion - еще сырая, BitKeeper - проприетарная, Arch - нет разделения 
прав доступа  и т.д.

На самом деле нужно смотреть код всех их, выбирать наиболее 
понравившуюся, списываться с авторами и дорабатывать до необходимого нам 
состояния.

Rgds,
Rider

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