From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 5 Aug 2003 20:49:38 +0300 From: Alexander Bokovoy To: ALT Devel discussion list Subject: Re: [devel] sandman =?koi8-r?Q?=CE?= =?koi8-r?Q?=C1?= cvs.altlinux.org Message-ID: <20030805174938.GA22332@sam-solutions.net> Mail-Followup-To: ALT Devel discussion list References: <3F2E1B00.4040205@altlinux.com> <20030804084612.GB15251@basalt.office.altlinux.org> <3F2E1E8A.7020400@altlinux.com> <20030804090027.GA15443@basalt.office.altlinux.org> <3F2E217D.4010202@altlinux.com> <20030804090859.GA15677@basalt.office.altlinux.org> <20030804095035.GA30926@sam-solutions.net> <20030805093239.GC31934@sam-solutions.net> <20030805173326.GA16249@basalt.office.altlinux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20030805173326.GA16249@basalt.office.altlinux.org> X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.2 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2003 17:49:53 -0000 Archived-At: List-Archive: List-Post: 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.