Re: [devel] Q: cvs inquiry

["Dmitry V. Levin" <ldv@fandra.org>]

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

On Mon, Nov 20, 2000 at 12:25:15PM +0300, Mikhail Zabaluev wrote:
> > > > Чем меньше файлов используется для хранения информации о пакете,
> > > > тем лучше. И так уже сделано практически все: в Source можно указывать
> > > > URL, чем пользуются многие, в том числе MandrakeSoft. Догадываетесь, что
> > > > это они делают неспроста?
> > > 
> > > Да, я догадываюсь. Но мне привязка к specам не нравится. Нам нужно не
> > > одно поле, а несколько (в моей концепции). Причем другие поля ну уж
> > > никак не увязываются с сутью spec файлы, они будут специально для
> > > нашего cvs.
> > Все-таки я бы остановился сейчас на хранении информации внутри
> > spec-файла. Временные ограничения несколько поджимают нас в выборе
> > вариантов для первого воплощения идеи, а использование объединенной
> > системы облегчит тестирование.
> > 
> > Для оповещения об обновлениях в репозитарии можно для начала принять
> > такой вариант: при отправке spec-файла поле Group используется в
> > качестве группы для заинтересованных разработчиков, которые должны
> > получать информацию об этом обновлении. Если указанный в spec-файле
> > мэйнтейнер отсутствует в текущем списке, он добавляется в него. Так, по
> > крайней мере, можно избежать проблем с координацией проектов внутри
> > одной категории, да и обрабатывать проще. Но это решение "на первое
> > время", хотя его можно и развить далее.
> 
> Не знаю, имеет ли смысл привязка интересов разработчиков только к группам
> RPM. Взять хотя бы Development/C - масса совершенно разных по
> тематическому значению пакетов.

Это верно.

> Мне кажется, информация о заинтересованных разработчиках все-таки
> не является неотъемлемой от пакета, тем более, что она может меняться
> чаще, чем пакет. Здесь я согласен с Петром: такие данные, не имеющие
> непосредственного представления средствами RPM, лучше конфигурировать

Даже данные по закачке исходников сложно уместить в spec-файл без
добавления новых тэгов (или псевдотэгов).
Пример из cvs.spec:
Source: ftp://ftp.cvshome.org/pub/%name-%version/%name-%version.tar.bz2

Наиболее разумно держать информацию для уведомлений в базе данных и
управлять через web (ибо пакетов сотни). Единственная проблема - на
сервере logic.ru совершенно не заинтересованный ни в чем подобном и потому
совершенно непрошибаемый администратор (Вы, наверное, об этом уже
догадались) - там нет никакого сервера базы данных; а если будет - то
очень не скоро, и не тот, который нужен, и не та версия, которая работает, и ...

> отдельно. На первое же время достаточно будет публиковать все рапорты в
> общем списке рассылки - в этом или в специально созданном только для
> автоматических объявлений.

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


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 --]