From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <3F30B248.7090602@altlinux.com> Date: Wed, 06 Aug 2003 11:46:16 +0400 From: Anton Farygin Organization: ALT Linux User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.4) Gecko/20030710 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: ALT Devel discussion list Subject: Re: [devel] sandman =?KOI8-R?Q?=CE=C1_cvs=2Ealtlinux=2Eorg?= 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> <20030805175822.GA16612@basalt.office.altlinux.org> In-Reply-To: <20030805175822.GA16612@basalt.office.altlinux.org> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB1026C1BC6B883000AFCFE37" Content-Transfer-Encoding: 8bit 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: Wed, 06 Aug 2003 07:46:27 -0000 Archived-At: List-Archive: List-Post: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB1026C1BC6B883000AFCFE37 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Dmitry V. Levin пишет: > 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-файла роли не играет. Дим, я вчера наваял совсем простенький скрипт, конвертирующий kernel CVS в sandman репозитарий (для коммита). В принципе - конверталку мы напишем. Но могу сказать одно - работать с такими файлами неудобно - дисковые операции поиска спеков значительно замедляются (приходится еще анализировать содержимое каждого файла). Я бы рекомендовал разработчикам Sandman внести в него изменения, которые позволят держать в репозитарии спеки с более человеческим именем (+.spec) Ну а если быть более честным, то имя спек-файла не имеет никакого значения, ибо одна тривиальная операция: rpm -q --queryformat='%{NAME}\n' --specfile <имя спек-файла> вернет вам имя вашего спека. Rgds, Rider --------------enigB1026C1BC6B883000AFCFE37 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/MLJNqohfd2vlwKsRAjnAAKCyob1sk1v0f9HbzDKZRw5HeV02ygCeI1DS aJikDcdB9OS2lZhSLVe04I0= =miiH -----END PGP SIGNATURE----- --------------enigB1026C1BC6B883000AFCFE37--