[devel] Q: cvs inquiry

Dmitry V. Levin =?iso-8859-1?q?ldv_=CE=C1_fandra=2Eorg?=
Пт Ноя 24 11:47:06 MSK 2000


On Fri, Nov 24, 2000 at 01:30:23AM +0300, Mikhail Zabaluev wrote:
> > > Не понимаю. Если в 'Source:' задан URL с точностью плюс-минус архивный
> > > суффикс, то и искать ничего не нужно. Если имеется в виду поиск локальных
> > > файлов, то их имена из URL вычленить тоже не представляется сложным -
> > > rpm ведь справляется.
> > 
> > Очень просто:
> > Когда URL записан в виде
> > ftp://ftp.cvshome.org/pub/%name-%version/%name-%version.tar.bz2,
> > то мне очевидно, что в поиске свежей версии требуется найти все
> > ftp://ftp.cvshome.org/pub/cvs-*/cvs-*.tar.gz, отсортировать по номеру
> > версии, найдя, таким образом, самую свежую, которую и скачать. Слабо
> > написать алгоритм, который сможет реализовать подобные схемы, пользуясь
> > _только_ знанием URL'а?
> 
> Во имя всего святого, зачем? За обновлением версий пусть следит
> maintainer. Не для роботов это - решать, какие исходники пойдут в дело.
> Может, в этом месте еще нестабильных версий навалено, откуда знать?

Некоторые дистрибутивы так делают, и это имеет смысл, особенно когда на
одного miantainer'а приходится более сотни пакетов *sigh*

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

И в мыслях не было!

Это просто невозможно - собирать и тестировать пакеты на живом сервере.

> CVS-дерево. Можно и вообще отказаться, если выделить машину, которая будет
> регулярно делать update с этого CVS и собирать измененные пакеты у себя. И

Так и было задумано, только я полагаю, что разумнее все-таки осуществлять
сборку по инициативе packager'а.

> вообще - у кого нет машины, чтобы тестировать свои пакеты, поднимите руку
> :) (Хотя, вопрос скорее в толщине и дороговизне пуповины-Интернета).
> А пробивать /dev/zero и /dev/shmero у админов, у которых одна мысль о том,
> что в систему будут закачиваться мегабайты неизвестно чего и потом
> что-то из этого будет запускаться на исполнение, вызывает икоту - долгая
> история.

Об этом и речи не было, чтобы закачиваемое на сервер там запускалось (см.
выше).

> Кстати, об икоте: есть ли идеи насчет автоматической проверки подлинности
> исходников? Скажем, верификации сигнатур там, где они есть?

Я всегда это делаю.
Автоматическая проверка вряд ли годится, а вот maintainer'ская вполне
разумна.

Предполагается, что maintainer проверяет подписи у себя перед началом
сборки, а перед commit'ом убеждается, что у него и на удаленном
CVS-сервере оказались одинаковые файлы (закаченные разными путями)
посредством md5sum.


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.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 232 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20001124/03ab33fc/attachment-0001.bin>


Подробная информация о списке рассылки Devel