[devel] Q: package repository

[devel] Q: package repository

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

Greetings!

Первоначально я планировал разработать этот вопрос самаму, несколько
позднее - разработать и обсудить здесь, однако так сложилось, что времени
сосредоточиться на решении этого вопроса у меня нет, а решать его надо.

Итак, при наличии двух и более постоянных разработчиков (в отличии от
RE <= 7.0) для нормальной продуктивной работы требуется package
repository. Основные требования, предъявляемые к subj, таковы:

+ Revision Control:
  Единица модульности - пакет.
  Хранится более одного релиза (каждого пакета), changelog к каждому
  релизу, и т.д (как в RCS, CVS, etc.)
+ Минимальный траффик:
  Требуется в максимальной степени избежать издишнюю перекачку
  многомегабайтных "pristine sources" туда-сюда при commit'ах и
  checkout'ах, в предположении, что package repository server расположен
  на быстром канале, в отличие от разработчика.
+ Возможность сопряжения с подсистемами автоматической сборки и
  автоматического обновления "pristine sources" (этих подсистем пока нет).

Что будет единицей хранения (файл, архив файлов, etc.), зависит от
реализации.

Жду Ваших идей.


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.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [devel] Q: package repository

[Alexander Bokovoy]

"Dmitry V. Levin" wrote:
> 
> Greetings!
> 
> Первоначально я планировал разработать этот вопрос самаму, несколько
> позднее - разработать и обсудить здесь, однако так сложилось, что времени
> сосредоточиться на решении этого вопроса у меня нет, а решать его надо.
> 
> Итак, при наличии двух и более постоянных разработчиков (в отличии от
> RE <= 7.0) для нормальной продуктивной работы требуется package
> repository. Основные требования, предъявляемые к subj, таковы:
> 
> + Revision Control:
>   Единица модульности - пакет.
>   Хранится более одного релиза (каждого пакета), changelog к каждому
>   релизу, и т.д (как в RCS, CVS, etc.)
> + Минимальный траффик:
>   Требуется в максимальной степени избежать издишнюю перекачку
>   многомегабайтных "pristine sources" туда-сюда при commit'ах и
>   checkout'ах, в предположении, что package repository server расположен
>   на быстром канале, в отличие от разработчика.
> + Возможность сопряжения с подсистемами автоматической сборки и
>   автоматического обновления "pristine sources" (этих подсистем пока нет).
> 
> Что будет единицей хранения (файл, архив файлов, etc.), зависит от
> реализации.
> 
> Жду Ваших идей.
Предлагаю как вариант следующую систему:
1. Репозитарий разбивается на две части -- оригинальные исходные тексты и наши патчи.
Первые хранятся в виде отдельных каталогов с оригинальными tar.bz2 (tar.gz) и
обновляются при обновлении версии продукта. Вторые находятся в CVS, где каждый модуль
совпадает по имени с каталогом в первой части.

2. Каждый приходящий патч при commit проверяется на наличие в имени наиболее
распространенных окончаний сжатых файлов (.gz, .bz2, .tar.они-же, другие варианты),
раскручивается и выполняется diff с последней версией в репозитарии (которая тоже
раскручивается перед сравнением). Таким образом, фактически, подменяется способ
хранения пакетов в CVS: CVS ведет diff-ы между патчами для бинарных исправлений и
ведет историю обычных файлов (например, SPECS) как обычно.

3. Вторая часть репозитария представляет собой фактически содержимое nosrc.rpm.
-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |    Aurora R&D team 
Minsk Linux Users Group |    www.minsk-lug.net    |  www.aurora-linux.com  
   IPLabs Linux Team    |     linux.iplabs.ru     | Architecte Open Source
-- With clothes the new are best, with friends the old are best.
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] Q: package repository

[Mikhail Zabaluev]

Hello Dmitry,

On Tue, Oct 24, 2000 at 16:38 +0400, Dmitry V. Levin wrote:
>
> Greetings!
> 
> Первоначально я планировал разработать этот вопрос самаму, несколько
> позднее - разработать и обсудить здесь, однако так сложилось, что времени
> сосредоточиться на решении этого вопроса у меня нет, а решать его надо.
> 
> Итак, при наличии двух и более постоянных разработчиков (в отличии от
> RE <= 7.0) для нормальной продуктивной работы требуется package
> repository. Основные требования, предъявляемые к subj, таковы:
> 
> + Revision Control:
>   Единица модульности - пакет.
>   Хранится более одного релиза (каждого пакета), changelog к каждому
>   релизу, и т.д (как в RCS, CVS, etc.)

Если будет выбран CVS, неплохо было бы автоматизировать changelog в spec
- записывать туда комментарии, введенные при commit'e.

> + Возможность сопряжения с подсистемами автоматической сборки и
>   автоматического обновления "pristine sources" (этих подсистем пока нет).

Опять же, по commit или rtag можно запускать сборку и отправлять
доклад разработчику (адрес берется из тэга Packager в spec). Исходники
можно требовать указывать в виде URL и для сборки, если локальной копии
нет, забирать wget'ом или аналогичным софтом, предусмотрев подстраховку,
например: указан .bz2 -> не найден -> пробуем .gz -> есть -> выкачиваем
-> переупаковываем.

> Что будет единицей хранения (файл, архив файлов, etc.), зависит от
> реализации.

Присоединяюсь к мнению Александра: для sources - архивы вне revision
control, все остальное отслеживать в виде файлов. Дополнение: добавленные
бинарные файлы (иконки и т.п.) заливать минуя revision control, видимо, в
ту же иерархию, где будут лежать исходники.

-- 
Stay tuned,
  MhZ                                    mailto:mookid@sigent.ru
-----------
The good life was so elusive
It really got me down
I had to regain some confidence
So I got into camouflage
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

[devel] Re: Q: package repository

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 4724 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]