[devel] sandman на cvs.altlinux.org

[Anton Farygin]

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
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 252 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20030806/63580025/attachment-0001.bin>