[devel] perl packages

[Andrey Brindeew]

On Thu, Sep 04, 2003 at 06:18:45PM +0400, Alexey Tourbin wrote:
> наверное все уже почувствовали, что настало время повысить качество
> сборки пакетов.  Для этого мы изобретаем хитроумные механизмы и проч.
> Короче, предлагаю новые правила сборки перловых пакетов:

Я против глобальных изменений. "Лучшее - враг хорошего".
 
> - пакет должен пересобираться в hasher'е (или в sandman'е)

У меня hasher'а никогда, видимо, не будет. Ибо по моим сведениям,
hasher'у нужно полное локальное дерево Сизифа (т.к. он не умеет
пользоваться удаленными репозитариями).

А если учесть еще то, что hasher & sandman - всё-таки разные, то полного
счастья опять мы не получаем. У разработчика всё будет прекрасно
собираться в sandman'е, а у incominger'а - не будет в hasher'е. Или
наоборот.

> - пакет должен иметь адекватные зависимости BuildRequires, полученные
>   с помощью buildreq (как минимум perl-devel); замечание: пока иногда
>   придется делать buildreq --args=-bi *.spec

Вроде я так всегда и делаю.

> - пакет должен собираться с помощью макросов %perl_vendor_build и
>   %perl_vendor_install (кстати, они умеют брать параметры)

Дока есть? Или как обычно, "look into sources"? :-(

> - пакет должен проходить все тесты; исключения:
>   + требуется запуск X
>   + требуется запуск системных сервисов
>   + подразумевается специальная сетевая активность

Тесты на подключение к БД сюда попадают? Для примера смотреть
perl-Template.

>   + подразумеваются специальные требования к среде сборки (будет уточнено)
>   В случае исключения maintainer должен под честное слово и gpg подпись
>   проверить в полноценной сборочной среде, что все тесты проходят.

>   Напоминаю, что тесты можно отключать избирательно (в случае исключений).

Каким образом?

> - все перловые файлы в пакете должны проходить 'perl -c' syntax check на
>   стадии find-requires; это связано в том числе и с тем, что новый
>   скрипт perl.req, который может появиться уже в ближайшей сборке
>   rpm-build, предъявляет по сути эквивалентное требование

Разумно, с этим трудно не согласиться.

> Думаю, что со временем аналогичные по духу требования будут предъявлены
> ко всем пакетам.
> 
> Мелочи:
> 
> - не надо писать Summary: %module module for Perl

Что надо писать в Summary?

> - рекомендуется писать Url: http://serch.cpan.org/dist/%module/

Так в новых сборках своих пакетов и делаю.

> Теперь статистика.  По состоянию на вчера в SRPMS.classic имеется 154
> perl* пакетов.  60 из них не отвечает новым требованиями, т.е., попросту
> говоря, не пересобираются.  Многие из них не пересобираются "вообще" (на
> стадии %build).  Список пакетов, которые не пересобираются:
> 

Вопросы по поводу моих пакетов ушли личной почтой.

> Предлагается привести пакеты в соответствие с новыми требованиями.
> В сущности, несколько maintainer'ов получили это предложение ещё вчера.
> Отказ от предложения может привести к перемещению пакета в orphaned. :)

Сурово. Посмотрим, как багзилла будет жить без perl-Template - он ведь
тоже в списке! :-)

-- 
WBR, Andrey Brindeew.
"No one person can understand Perl culture completely"
(C) Larry Wall.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 245 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20030905/55fa2a94/attachment-0001.bin>