[devel] sandman на cvs.altlinux.org
Alexander Bokovoy
=?iso-8859-1?q?a=2Ebokovoy_=CE=C1_sam-solutions=2Enet?=
Вт Авг 5 13:32:39 MSD 2003
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.
Подробная информация о списке рассылки Devel