[devel] sandman на cvs.altlinux.org
Dmitry V. Levin
=?iso-8859-1?q?ldv_=CE=C1_altlinux=2Eorg?=
Вт Авг 5 21:33:26 MSD 2003
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
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип : application/pgp-signature
Размер : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20030805/e4e135d2/attachment-0001.bin>
Подробная информация о списке рассылки Devel