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