[devel] perl и модули из собираемого пакета

[devel] perl и модули из собираемого пакета

[Andrew Kornilov]

Привет всем.

Обновляю свой же пакет, request-tracker. Решил включить давно выключенный
AutoReq для perl-а. Включил, получаю следующее:
Can't locate RT/Interface/CLI.pm in @INC (@INC contains: /usr/lib/rt/lib 
/usr/lib/rt/local/lib /usr/lib/rpm /etc/perl5 /usr/lib/perl5/x86_64-linux
/usr/lib/perl5 /usr/lib/perl5/vendor_perl/x86_64-linux
/usr/lib/perl5/vendor_perl /usr/local/lib/perl5/site_perl/5.8.8/x86_64-linux
/usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl .) 
at /home/hiddenman/tmp/request-tracker-buildroot/usr/lib/rt/bin/rt-count line
45.
Файл rt-count в строке 45 содержит:
use RT::Interface::CLI qw(CleanEnv GetCurrentUser GetMessageContent loc);

Соответствующий файл находится в
/home/hiddenman/tmp/request-tracker-buildroot/usr/lib/rt/lib в виде
RT/Interface/CLI.pm

Почитав README.ALT из rpm-build-perl и поискав по рассылке, попробовал
использовать макросы:
%define _perl_lib_path %_libdir/%name/lib/
%add_perl_lib_path %_libdir/%name/lib/
в том числе, добавляя %buildroot в начало.

Не помогает. Стабильно пишет вышеуказанную ошибку, с тем же самым @INC,
что бы я не писал в вышеуказанные макросы.
Или я что-то не так делаю или что-то не работает.
Просьба подсказать.

-- 

Re: [devel] perl и модули из собираемого пакета

[Nikolay A. Fetisov]

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

On Mon, 25 Feb 2008 23:29:24 +0200
Andrew Kornilov wrote:

> Обновляю свой же пакет, request-tracker. Решил включить давно выключенный
> AutoReq для perl-а. Включил, получаю следующее:
> Can't locate RT/Interface/CLI.pm in @INC (@INC contains: /usr/lib/rt/lib 
> /usr/lib/rt/local/lib /usr/lib/rpm /etc/perl5 /usr/lib/perl5/x86_64-linux
> /usr/lib/perl5 /usr/lib/perl5/vendor_perl/x86_64-linux
Сборка идёт на x86_64?                       ^^^^

> ...
> Почитав README.ALT из rpm-build-perl и поискав по рассылке, попробовал
> использовать макросы:
> %define _perl_lib_path %_libdir/%name/lib/
Этого вполне достаточно - с заменой %_libdir на %_libexecdir.

-- 
С уважением,	
Николай Фетисов

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] perl и модули из собираемого пакета

[Andrew Kornilov]

"Nikolay A. Fetisov" <naf-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:
>> Can't locate RT/Interface/CLI.pm in @INC (@INC contains: /usr/lib/rt/lib 
>> /usr/lib/rt/local/lib /usr/lib/rpm /etc/perl5 /usr/lib/perl5/x86_64-linux
>> /usr/lib/perl5 /usr/lib/perl5/vendor_perl/x86_64-linux
> Сборка идёт на x86_64?                       ^^^^
Да. 
>
>> ...
>> Почитав README.ALT из rpm-build-perl и поискав по рассылке, попробовал
>> использовать макросы:
>> %define _perl_lib_path %_libdir/%name/lib/
> Этого вполне достаточно - с заменой %_libdir на %_libexecdir.
Гм. А почему надо менять на libexecdir и где об этом сказано? Потому, что
x86_64? А если у меня target noarch, libdir же будет правильно указывать. Меня
даже больше интересует, почему в ошибке в @INC нет моего пути. 
-- 

Re: [devel] perl и модули из собираемого пакета

[Nikolay A. Fetisov]

[-- Attachment #1.1: Type: text/plain, Size: 1380 bytes --]

On Tue, 26 Feb 2008 15:36:44 +0200
Andrew Kornilov wrote:

> "Nikolay A. Fetisov" <naf-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:
> ...
> > Сборка идёт на x86_64?
> Да. 

На x86_64 %_libdir = /usr/lib64.

> >
> >> ...
> >> Почитав README.ALT из rpm-build-perl и поискав по рассылке, попробовал
> >> использовать макросы:
> >> %define _perl_lib_path %_libdir/%name/lib/
> > Этого вполне достаточно - с заменой %_libdir на %_libexecdir.
> Гм. А почему надо менять на libexecdir и где об этом сказано? Потому, что
> x86_64? А если у меня target noarch, libdir же будет правильно указывать. 

%_libexecdir = /usr/lib и на x86_64, и на i586. Посмотрите лог сборки в 
ftp://ftp.altlinux.org/pub/people/incominger/logs/rebuild/x86_64/
То, что в Sisyphus попал пакет, собранный на i586 - это просто везение.

А самое правильное, наверное, перетаскивать всё из /usr/lib
в /usr/share. 

> Меня даже больше интересует, почему в ошибке в @INC нет моего пути. 

По рассмотрению rt.spec: нужен
%define _perl_lib_path %_libdir/%rtname/lib/

Для 3.6.6-alt1.rc1 патч к rt.spec приложил - для сборки на i586.
Трёх модулей, использующихся в пакете, в Sisyphus на данный момент нет.
Использующие их места, соответственно, выброшены через
%add_findreq_skiplist. Также из пакета (и из поиска зависимостей)
выкинуты тесты.

-- 
С уважением,
Николай Фетисов

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: rt.spec.patch --]
[-- Type: text/x-patch; name=rt.spec.patch, Size: 1094 bytes --]

diff --git a/rt.spec b/rt.spec
index d3cf755..142b825 100644
--- a/rt.spec
+++ b/rt.spec
@@ -46,8 +46,8 @@ Source5: %rtname-rt-count
 Source6: %rtname-rt-escalate
 
 BuildRequires: autoconf perl
-#AutoReqProv: noperl
-AutoReq: no
+AutoReqProv: perl, yes
+
 
 %define siteconfig %_sysconfdir/%rtname/RT_SiteConfig.pm
 
@@ -167,6 +167,11 @@ Requires: perl(DBD/SQLite.pm)
 %description sqlite
 SQLite support for the %name
 
+%add_findreq_skiplist */bin/mason_handler.svc */bin/standalone_httpd */bin/webmux.pl
+%add_findreq_skiplist */lib/RT/Interface/Email/Auth/GnuPG.pm
+%add_findreq_skiplist */lib/RT/Interface/Web/Standalone.pm
+%add_findreq_skiplist */lib/t/create_data.pl
+%define _perl_lib_path %_libdir/%rtname/lib/
 
 %prep
 
@@ -362,6 +367,8 @@ echo ""
 %attr(0640,root,%webgrp) %config(noreplace) /%_libdir/%rtname/local/etc/*
 %attr(0640,root,root) %config(noreplace) %apacheconfig
 
+%exclude %_libdir/%rtname/lib/t*
+
 %files ru
 %attr(-,root,%webgrp) %_libdir/%rtname/local/etc/initialdata
 %attr(-,root,%webgrp) %_libdir/%rtname/local/po/ru.po

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] perl и модули из собираемого пакета

[Andrew Kornilov]

"Nikolay A. Fetisov" <naf-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:
>> > Сборка идёт на x86_64?
>> Да. 
> На x86_64 %_libdir = /usr/lib64.
Я в курсе. Но при target noarch %_libdir таки равна /usr/lib. В общем, я
теплое с мягким перепутал. BuildArch: noarch ни на что не влияет при сборке,
как мне только что объяснили. Только на то, куда он будет положен.
> %_libexecdir = /usr/lib и на x86_64, и на i586. Посмотрите лог сборки в 
Когда-то там и был libexecdir, но потом я почему-то поменял на libdir. В мае
2006 еще. Были, значит, причины или кто-то подсказал. Похоже, надо возвращать
обратно.
> А самое правильное, наверное, перетаскивать всё из /usr/lib
> в /usr/share. 
Ну всё стороннее ПО ищет библиотеки и модули в */lib/*, а не в share. Можно,
конечно, и туда это переместить, но будет ли от этого легче?
perl у нас лежит в /usr/lib, в /usr/lib64 и /usr/share нет ничего (по крайней
мере, у меня на машине, где x86_64).
>> Меня даже больше интересует, почему в ошибке в @INC нет моего пути. 
> По рассмотрению rt.spec: нужен
> %define _perl_lib_path %_libdir/%rtname/lib/
Так не помогает. Что с макросами, что с полным путем. Пробовал всё доступное.
Видимо, есть еще что-то :) Сейчас перепроверю еще раз.
> Для 3.6.6-alt1.rc1 патч к rt.spec приложил - для сборки на i586.
> Трёх модулей, использующихся в пакете, в Sisyphus на данный момент нет.
> Использующие их места, соответственно, выброшены через
> %add_findreq_skiplist. Также из пакета (и из поиска зависимостей)
> выкинуты тесты.
Ну это, скажем так, старый спек, реально я давно 3.7 собираю и использую, но в
Сизифе его нет еще. Учту изменения, спасибо. Теоретически, все модули сейчас
должны быть. Проверю.
Вообще спек достаточно кривой и тянется еще с 2004 года, когда x86_64 еще не
было. Собственно, попробую вернуться на libexecdir и сообщу, как оно.

P.S. Т.к. на gmane эта рассылка в read-only, я отвечаю через почту. Получается
разрыв треда или нормально отображается?
-- 

Re: [devel] perl и модули из собираемого пакета

[Andrew Kornilov]

"Nikolay A. Fetisov" <naf-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:
> Для 3.6.6-alt1.rc1 патч к rt.spec приложил - для сборки на i586.
> Трёх модулей, использующихся в пакете, в Sisyphus на данный момент нет.
> Использующие их места, соответственно, выброшены через
> %add_findreq_skiplist. Также из пакета (и из поиска зависимостей)
> выкинуты тесты.
В общем, при включенном AutoReqProv поиск зависимостей в hsh-shell начинает
хотеть все модули перла, которые требуются для работы данного приложения.
Получается, мне всё это нужно прописывать в BuildReq? buildreq, естественно,
тоже прерывается на той же самой ошибке.
-- 

Re: [devel] perl и модули из собираемого пакета

[Nikolay A. Fetisov]

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

On Wed, 27 Feb 2008 03:06:03 +0200
Andrew Kornilov wrote:

> ...
> В общем, при включенном AutoReqProv поиск зависимостей в hsh-shell начинает
> хотеть все модули перла, которые требуются для работы данного приложения.

Не только, при сборке вне hasher - тоже.

> Получается, мне всё это нужно прописывать в BuildReq? buildreq, естественно,
> тоже прерывается на той же самой ошибке.

Разумеется. Поскольку при этом заодно обнаруживаются те модули, которые
приложением используются, но в репозитории отсутствуют. Как, в случае с
3.6.6, Mail::GnuPG, HTTP::Server::Simple::Mason, и т.д.

Ещё хорошо бы разобраться предупреждениями о повторно
упакованных/забытых файлах...

-- 
С уважением,	
Николай Фетисов

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] perl и модули из собираемого пакета

[Nikolay A. Fetisov]

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

On Tue, 26 Feb 2008 23:41:41 +0200
Andrew Kornilov wrote:

> "Nikolay A. Fetisov" <naf-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:
> ...
> > А самое правильное, наверное, перетаскивать всё из /usr/lib
> > в /usr/share. 
> Ну всё стороннее ПО ищет библиотеки и модули в */lib/*, а не в share. Можно,
> конечно, и туда это переместить, но будет ли от этого легче?
> perl у нас лежит в /usr/lib, в /usr/lib64 и /usr/share нет ничего (по крайней
> мере, у меня на машине, где x86_64).

Одно дело Perl и библиотечные модули, другое - приложения. Стороннее ПО
к модулям самого RT вряд ли обращать будет, иначе эти модули были бы в
%perl_vendor_privlib . В Debian  RT лежит в %_libexecdir:
http://packages.debian.org/etch/all/request-tracker3.6/filelist

> ...
> P.S. Т.к. на gmane эта рассылка в read-only, я отвечаю через почту. Получается
> разрыв треда или нормально отображается?
Нормально:
http://lists.altlinux.org/pipermail/devel/2008-February/thread.html#70285

-- 
С уважением,
Николай Фетисов

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] perl и модули из собираемого пакета

[Andrew Kornilov]

"Nikolay A. Fetisov" <naf-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:
>> В общем, при включенном AutoReqProv поиск зависимостей в hsh-shell начинает
>> хотеть все модули перла, которые требуются для работы данного приложения.
> Не только, при сборке вне hasher - тоже.
Ну это понятно. Я для чистоты эксперимента.
>> Получается, мне всё это нужно прописывать в BuildReq? buildreq, естественно,
>> тоже прерывается на той же самой ошибке.
> Разумеется. Поскольку при этом заодно обнаруживаются те модули, которые
> приложением используются, но в репозитории отсутствуют. Как, в случае с
> 3.6.6, Mail::GnuPG, HTTP::Server::Simple::Mason, и т.д.
Тут, конечно, спорный вопрос. В пакете у них предусмотрена своя проверка
наличия нужных модулей, в том числе с привязкой к версии. И если что-то не
требуется, то оно и не требуется. Но наши с ними понятия о том же perl-base
могут расходиться, у нас это может быть пустой пакет, а у них считаться
пакетом с такими-то модулями. В общем, нужен комплекс и из их проверки,
где проверяются и версии модулей, и из нашего findreq, который может найти
отсутствующие.
Что касается Mason Server, то он требуется только для standalone версии.
Не знаю, нужна ли эта зависимость. Если делать качественный продукт,
то пакет нужно распилить еще на кучу подпакетов, сделать поддержку apache2,
как просил lav@, standalone и т.д. и т.п. Делать и тестировать только некому.
До момента сборки все ставили этот RT с помощью -MCPAN install everything :)
То же самое касается Zope+Plone. Которые я обещал предоставить общественности
для допиливания, но уже благополучно забыл, что там не так и которые таки
проще поставить с помощью make && make install.
> Ещё хорошо бы разобраться предупреждениями о повторно
> упакованных/забытых файлах...
Давно это дело было, несколько раз перекраивался пакет. Честно говоря, я в
своё время с трудом разобрался, что там к чему, пропатчил и запаковал и оно
как-то работало. Потом несколько раз переделывал и что-то ломалось. Боюсь, что
сейчас опять полезу и опять поломаю.
-- 

Re: [devel] perl и модули из собираемого пакета

[Andrew Kornilov]

"Nikolay A. Fetisov" <naf-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:
>> Ну всё стороннее ПО ищет библиотеки и модули в */lib/*, а не в share. Можно,
>> конечно, и туда это переместить, но будет ли от этого легче?
>> perl у нас лежит в /usr/lib, в /usr/lib64 и /usr/share нет ничего (по крайней
>> мере, у меня на машине, где x86_64).
> Одно дело Perl и библиотечные модули, другое - приложения. Стороннее ПО
> к модулям самого RT вряд ли обращать будет, иначе эти модули были бы в
Смотря что считать сторонними. Для RT существует немаленькое количество
различных расширений, которые являются отдельными продуктами. Два из
них в Сизифе (RTFM и AT). Сам RT состоит из 124 пакетов, 114 из которых
на CPAN.
> %perl_vendor_privlib . В Debian  RT лежит в %_libexecdir:
> http://packages.debian.org/etch/all/request-tracker3.6/filelist
Да, я уже переделал спеки снова на libexecdir и прочие штуки почистил,
посмотрим, как оно соберется, icesik@ уже успел собрать недостающие модули,
спасибо ему :)
>> P.S. Т.к. на gmane эта рассылка в read-only, я отвечаю через почту. Получается
>> разрыв треда или нормально отображается?
> Нормально:
> http://lists.altlinux.org/pipermail/devel/2008-February/thread.html#70285
Отлично.
-- 

Re: [devel] perl и модули из собираемого пакета

[Igor Zubkov]

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

27.02.08, Andrew Kornilov написал(а):
> Да, я уже переделал спеки снова на libexecdir и прочие штуки почистил,
>  посмотрим, как оно соберется, icesik@ уже успел собрать недостающие модули,
>  спасибо ему :)

Итак. Я собрал rt вроде более или менее правильно. Для начала у нас в
Сизифе отсутствуеют три перл модуля которые испоьзуются в rt. Это
GnuPG-Interface, HTTP-Server-Simple-Mason и Test-HTTP-Server-Simple.
Спеки для них в аттаче. После этого rt собирает с включённым поиском
зависимостей в перле. Я запустил на rt.spec buildreq -bi и тот
выставил правильные сборочные зависимости. Так же, в спеке прибиты
гвоздями ручные зависимости на перл модули, я думаю что их стоит все
убрать. Пусть perl.req отрабатывает свой хлеб. Подпаченный спек тоже
приложен.

Рекомендации по нему у меня сейчас только одна -- убрать все ручные зависимости.

-- 
icesik

[-- Attachment #2: perl-GnuPG-Interface.spec --]
[-- Type: application/octet-stream, Size: 1374 bytes --]

[-- Attachment #3: perl-HTTP-Server-Simple-Mason.spec --]
[-- Type: application/octet-stream, Size: 1152 bytes --]

[-- Attachment #4: perl-Test-HTTP-Server-Simple.spec --]
[-- Type: application/octet-stream, Size: 2057 bytes --]

[-- Attachment #5: rt.spec --]
[-- Type: application/octet-stream, Size: 18861 bytes --]