From: "Dmitry V. Levin" <ldv@altlinux.org> To: ALT Devel discussion list <devel@altlinux.ru> Subject: Re: [devel] sandman на cvs.altlinux.org Date: Tue, 5 Aug 2003 21:33:26 +0400 Message-ID: <20030805173326.GA16249@basalt.office.altlinux.org> (raw) In-Reply-To: <20030805093239.GC31934@sam-solutions.net> [-- 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 --]
next prev parent reply other threads:[~2003-08-05 17:33 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-08-04 8:36 Anton Farygin 2003-08-04 8:46 ` Dmitry V. Levin 2003-08-04 8:51 ` Anton Farygin 2003-08-04 9:00 ` Dmitry V. Levin 2003-08-04 9:03 ` Anton Farygin 2003-08-04 9:08 ` Dmitry V. Levin 2003-08-04 9:17 ` Anton Farygin 2003-08-04 9:50 ` Alexander Bokovoy 2003-08-05 9:32 ` Alexander Bokovoy 2003-08-05 10:45 ` Anton Farygin 2003-08-05 10:52 ` Alexander Bokovoy 2003-08-05 11:06 ` Anton Farygin 2003-08-05 11:35 ` Alexey I. Froloff 2003-08-05 11:39 ` [devel] " Vitaly Ostanin 2003-08-05 12:06 ` [devel] " Anton Farygin 2003-08-05 12:23 ` Alexey I. Froloff 2003-08-05 17:40 ` Dmitry V. Levin 2003-08-05 17:56 ` Sergey Bolshakov 2003-08-05 18:01 ` Dmitry V. Levin 2003-08-05 18:13 ` Sergey Bolshakov 2003-08-05 18:15 ` Dmitry V. Levin 2003-08-12 14:26 ` Michael Shigorin 2003-08-12 14:57 ` Grigory Milev 2003-08-12 15:59 ` Dmitry V. Levin 2003-08-05 17:33 ` Dmitry V. Levin [this message] 2003-08-05 17:49 ` Alexander Bokovoy 2003-08-05 17:58 ` Dmitry V. Levin 2003-08-05 18:09 ` Alexander Bokovoy 2003-08-05 18:20 ` Dmitry V. Levin 2003-08-05 18:54 ` Sergey Bolshakov 2003-09-21 18:06 ` Dmitry V. Levin 2003-09-22 5:49 ` Anton Farygin 2003-09-22 21:37 ` Sviatoslav Sviridov 2003-09-23 8:06 ` Anton Farygin 2003-08-06 7:46 ` Anton Farygin 2003-08-06 8:02 ` Dmitry V. Levin 2003-08-06 8:49 ` Sergey Bolshakov 2003-08-05 18:12 ` [devel] " Alexey Tourbin 2003-08-05 18:17 ` Alexander Bokovoy 2003-08-05 18:18 ` Sergey Bolshakov 2003-08-13 17:05 ` [devel] " Ivan Zakharyaschev 2003-08-13 17:57 ` Alexander Bokovoy 2003-08-04 9:29 ` Alexey I. Froloff 2003-08-04 10:12 ` Dmitry V. Levin 2003-08-04 10:18 ` Anton Farygin 2003-08-04 10:22 ` Dmitry V. Levin 2003-08-04 10:25 ` Sergey Bolshakov 2003-08-04 10:30 ` Anton Farygin 2003-08-04 10:22 ` Victor V Ismakaev 2003-08-04 10:26 ` Dmitry V. Levin 2003-08-04 11:04 ` Victor V Ismakaev 2003-08-04 11:09 ` Dmitry V. Levin 2003-08-25 10:24 ` Stanislav Ievlev 2003-08-25 10:54 ` Anton Farygin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030805173326.GA16249@basalt.office.altlinux.org \ --to=ldv@altlinux.org \ --cc=devel@altlinux.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git