Greetings!

On Tue, Oct 24, 2000 at 05:33:14PM +0300, Alexander Bokovoy wrote:
> Предлагаю как вариант следующую систему:
> 1. Репозитарий разбивается на две части -- оригинальные исходные тексты и наши патчи.
> Первые хранятся в виде отдельных каталогов с оригинальными tar.bz2 (tar.gz) и
> обновляются при обновлении версии продукта. Вторые находятся в CVS, где каждый модуль
> совпадает по имени с каталогом в первой части.

On Tue, Oct 24, 2000 at 11:08:11PM +0400, Mikhail Zabaluev wrote:
> Присоединяюсь к мнению Александра: для sources - архивы вне revision
> control, все остальное отслеживать в виде файлов. Дополнение: добавленные
> бинарные файлы (иконки и т.п.) заливать минуя revision control, видимо, в
> ту же иерархию, где будут лежать исходники.

On Tue, Oct 24, 2000 at 05:33:14PM +0300, Alexander Bokovoy wrote:
> 2. Каждый приходящий патч при commit проверяется на наличие в имени наиболее
> распространенных окончаний сжатых файлов (.gz, .bz2, .tar.они-же, другие варианты),
> раскручивается и выполняется diff с последней версией в репозитарии (которая тоже
> раскручивается перед сравнением). Таким образом, фактически, подменяется способ
> хранения пакетов в CVS: CVS ведет diff-ы между патчами для бинарных исправлений и
> ведет историю обычных файлов (например, SPECS) как обычно.
> 
> 3. Вторая часть репозитария представляет собой фактически содержимое nosrc.rpm.

On Tue, Oct 24, 2000 at 11:08:11PM +0400, Mikhail Zabaluev wrote:
> Если будет выбран CVS, неплохо было бы автоматизировать changelog в spec
> - записывать туда комментарии, введенные при commit'e.
> 
> > + Возможность сопряжения с подсистемами автоматической сборки и
> >   автоматического обновления "pristine sources" (этих подсистем пока нет).
> 
> Опять же, по commit или rtag можно запускать сборку и отправлять
> доклад разработчику (адрес берется из тэга Packager в spec). Исходники
> можно требовать указывать в виде URL и для сборки, если локальной копии
> нет, забирать wget'ом или аналогичным софтом, предусмотрев подстраховку,
> например: указан .bz2 -> не найден -> пробуем .gz -> есть -> выкачиваем
> -> переупаковываем.

Мне кажется более удобной следующая схема:

1. Содержимое каждого пакета разбивается на 3 категории:
   spec, sources, patches:
 + В категорию sources попадают файлы, именуемые "pristine sources",
   которые закачиваются в хранилище минуя packager'а. Для этих файлов
   стоит реализовать автоматический поиск и закачку новых версий.
 + В категорию spec попадает один единственный файл. В отличие от двух
   других категорий, эта категория содержит ровно один файл для каждого
   пакета. Выделение этого файла в отдельную категорию обусловлено
   особенностями пост-обработки при commit'e и rtag'e, как верно заметил
   Михаил.
 + В категорию patches попадают все остальные файлы.

2. Имеет смысл хранить большое число версий файлов из категории spec и
   patches; по этой причине разумный способ хранения - CVS, текстовые файлы
   при этом хранятся обычным образом, а бинарные - с опцией "-kb".

3. Как правило, нет смысла хранить много версий pristine sources, однако
   желательно все же иметь 2-3 версии; специфика файлов этой категории -
   смена имени файла вместе с номером версии (в большинстве случаев), что
   затрудняет использование CVS; Однако, есть потребность в возможности
   делать checkout по всем файлам пакета за определенную дату либо по
   определенному тагу. Не ясно, как это можно реализовать без CVS.
   Вопрос остается открытым.

4. К сожалению, в процессе пост-обработки операций с файлами из repository
   нельзя рассчитывать на возможность воспользоваться данными из
   соответствующих spec-файлов. Это связано с несовпадением версий rpm,
   используемых на серверах хранения и сборки. Например, rpm <= 3.0.6-ipl4mdk
   не сможет извлечь информацию из kernel-2.2.17.spec. Следовательно,
   необходимо предусмотреть какой-то другой способ хранения/извлечения
   метаинформации о пакетах, тем более, что наверняка понадобится
   использовать какую-то информацию, которую нельзя поместить в spec-файл.
   Как один из вариантов хранения такой информации можно использовать базу
   данных на сервере.
   Вопрос остается открытым.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who it's friends are.