[devel] Re: perl packages

[Alexey Tourbin]

On Fri, Sep 05, 2003 at 03:08:16PM +0400, Andrey Brindeew wrote:
> У меня hasher'а никогда, видимо, не будет. Ибо по моим сведениям,
> hasher'у нужно полное локальное дерево Сизифа (т.к. он не умеет
> пользоваться удаленными репозитариями).

Да.  Но некоторая часть пакетов, которая не пересобирается в hasher'е,
просто имеет неадекватный BuildReqruies.  Другая часть не собирается
из-за требования нового perl.req.  У hasher'а нет какой-то собственной
принципиальной специфики.

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

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

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

Это связано со спецификой новых скриптов.  В процессе B::Deparse/`perl -c'
проходит стадия компиляции перлового кода, исполнение кода BEGIN и
загрузка всех модулей из use.  Поэтому могут цепляться дополнительные
файлы (хотя, по идее, то же саоме должно происходить в тестах).

> > - пакет должен собираться с помощью макросов %perl_vendor_build и
> >   %perl_vendor_install (кстати, они умеют брать параметры)
> 
> Дока есть? Или как обычно, "look into sources"? :-(

Доки нет.  Но есть man ExtUtils::MakeMaker, который описывает
стандартную процедуру сборки перловых пакетов.  Если пакет не собирается
с помощью стандартной процедуры, значит он кривой.

Из-за неясной мне пока специфики RPM, макросы специфического вида он не
берёт:

%perl_vendor_build --load-lazy

не работает.  Обходной путь:

ARGS=--load-lazy
%perl_vendor_build $ARGS
 
> > - пакет должен проходить все тесты; исключения:
> >   + требуется запуск X
> >   + требуется запуск системных сервисов
> >   + подразумевается специальная сетевая активность
> 
> Тесты на подключение к БД сюда попадают? Для примера смотреть

Да, попадают.

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

Если тесты физически выглядят как t/*.t, то можно удалить
соответствующие *.t файлы.  Возможно, при этом придется отредактировать
MANIFEST.  Пример из perl58.spec:

# skip some tests that fail under buildreq/strace or make dependencies
%ifdef __buildreqs
files="t/io/openpid.t
t/op/fork.t
t/op/stat.t
lib/diagnostics.t
lib/Pod/t/basic.t
lib/Term/Cap.t
ext/POSIX/t/waitpid.t"
%__rm -f $files
%__mv MANIFEST MANIFEST.orig
%__grep -Fv "$files" MANIFEST.orig > MANIFEST
%endif

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

Зачем этот модуль нужен, что он делает.

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

Может привести, а может и не привести. :)
Вчера пересобрал 10 пакетов...
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20030905/fd423ddb/attachment-0001.bin>