[devel] sandman на cvs.altlinux.org

[Alexander Bokovoy]

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.