From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 5 Aug 2003 21:58:22 +0400 From: "Dmitry V. Levin" To: ALT Devel discussion list Subject: Re: [devel] sandman =?koi8-r?Q?=CE?= =?koi8-r?Q?=C1?= cvs.altlinux.org Message-ID: <20030805175822.GA16612@basalt.office.altlinux.org> 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> <20030805174938.GA22332@sam-solutions.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <20030805174938.GA22332@sam-solutions.net> X-fingerprint: 9658 398D 181B 1200 8FC5 26B8 F6F8 846B C1E2 3429 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:58:25 -0000 Archived-At: List-Archive: List-Post: --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/L/A+9viEa8HiNCkRAux4AJ0aDDClUub9iTbik84t0YSZ9ZgRKgCfQbxv amwfK3XkOF+rEEYlFZ/GQKQ= =Ip3a -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6--