(cpan2rpm-2.027-alt3) например, при создании RTF-parser в секции files получаем: %files %perl_vendor_privlib/RTF-Parser/* и соответственно ошибка при сборке RPM build errors: File not found by glob: /usr/src/tmp/perl-RTF-Parser-buildroot/usr/lib/perl5/vendor_perl/RTF-Parser/* при использовании cpan2rpm-2.027-alt1 files имеет вид: %files %perl_vendor_privlib/* %perl_vendor_man3dir/*
Вы не указали, какой строка в files должна быть.
(В ответ на комментарий №1) > Вы не указали, какой строка в files должна быть. :) как в версии cpan2rpm-2.027-alt1 меня вполне устраивает %files %perl_vendor_privlib/*
(В ответ на комментарий №2) > (В ответ на комментарий №1) > > Вы не указали, какой строка в files должна быть. > :) как в версии cpan2rpm-2.027-alt1 меня вполне устраивает > > %files > %perl_vendor_privlib/* Это неправильно, и sisyphus_check не пропустит такой пакет. Я хотел бы узнать, какая строка будет правильной для данного пакета. А, там наверное будет %perl_vendor_privlib/RTF/RTF-Parser/ ?
(В ответ на комментарий №3) > %perl_vendor_privlib/RTF/RTF-Parser/ > ? Если я правильно понял правила наименования модулей perl и соответствующих им пакетов (архивов), то директории ABC-Module там в принципе не может быть. Речь идет о модуле ABC::Module В конкретном случае в %perl_vendor_privlib/ лежат две папки: RTF i386-linux и т.к. модуль написан иключительно на perl (т.е. - noarch), то достаточный минимум - %perl_vendor_privlib/RTF/*. Если бы были си-шные вставки, потребовалолась бы строка %perl_vendor_privlib/i386-linux/* (см. например perl-DBI). Кроме того, архив модуля содержит не совсем бесполезные утилиты rtf2html,rtf2text, которые после "компиляции" лежат в %buildroot/blib/script. Но, похоже, для помещения их в пакет, надо вручную править спек.
(В ответ на комментарий №4) ... > Кроме того, архив модуля содержит не совсем бесполезные утилиты > rtf2html,rtf2text, которые после "компиляции" лежат в %buildroot/blib/script. > Но, похоже, для помещения их в пакет, надо вручную править спек. Не очень понимаю, с чего вы взяли, что это возможно сделать автоматически. Но если хотите попробовать, всегда можете отредактировать /usr/bin/cpan2rpm и прислать исправление.
(В ответ на комментарий №5) > > Но, похоже, для помещения их в пакет, надо вручную править спек. > Не очень понимаю, с чего вы взяли, что это возможно сделать автоматически. ?! Не вижу здесь утверждения, что я считаю, что это возможно сделать автоматически. (Как вариант автоматизации этого порцесса - поместить все что предлагает изначальный пакет за минусом того чот уже упаковалось и man-ов в %doc секцию или отдельный doc-пакет)
(В ответ на комментарий №5) >...Но > если хотите попробовать, всегда можете отредактировать /usr/bin/cpan2rpm и > прислать исправление. Приехали. а как всеже с первопричиной бага? Позвольте повториться: cpan2rpm-2.027-alt1 выдает вполне рабочий spec-файл, из которого собирается вполне рабочий пакет. По поводу sisyphus_check не совсем понятно, на что он будет ругаться, т.к. мне, как рядовому пользователю, приходится собирать пакеты с опцией --no-sisyphus-check. А cpan2rpm - инструмент в основном для рядового пользователя. А для "разработчика" - лишь первый помощник (ввиду ком.№4 2-я часть :). IMHO.
(В ответ на комментарий №7) > (В ответ на комментарий №5) > >...Но > > если хотите попробовать, всегда можете отредактировать /usr/bin/cpan2rpm и > > прислать исправление. > > Приехали. > а как всеже с первопричиной бага? > Позвольте повториться: > cpan2rpm-2.027-alt1 выдает вполне рабочий spec-файл, из которого собирается > вполне рабочий пакет. Не соответствующий policy на perl-пакеты в Сизифе. > По поводу sisyphus_check не совсем понятно, на что он будет ругаться, т.к. мне, > как рядовому пользователю, приходится собирать пакеты с опцией > --no-sisyphus-check. А cpan2rpm - инструмент в основном для рядового Что не очень хорошо. > пользователя. А для "разработчика" - лишь первый помощник (ввиду ком.№4 2-я > часть :). IMHO. По моему мнению, cpan2rpm - инструмент для меня. Если вам не хватает пакетов в Сизифе, сообщите, я соберу. Текущая ситуация меня в общем-то устраивает, потому что человек хоть в спек заглянет при сборке пакета. Изменить "назад" я не могу, потому что старое поведение противоречит правилам. Исправлять до идеала мне некогда.
Похоже, мне "повезло" с пакетом: $ cat Makefile.PL use ExtUtils::MakeMaker; &WriteMakefile( NAME => 'RTF::Parser', EXE_FILES => [ 'bin/rtf2html', 'bin/rtf2text' ], DISTNAME => 'RTF-Parser', ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... Обрабатывая этот файл, cpan2rpm ( 505 $info->{module} ||= $meta{DISTNAME} || $meta{NAME}; ) присваивает $info->{module} значение RTF-Parser. Отсюда и проблема. Предлагаю следующий патч: $ diff -u /usr/bin/cpan2rpm cpan2rpm-my --- /usr/bin/cpan2rpm 2008-10-09 22:38:45 +0000 +++ cpan2rpm-my 2009-04-08 11:01:43 +0000 @@ -512,8 +512,8 @@ } $info->{module} = $info->{tarball}; $info->{module} =~ s/-(\d+\.?\d*)$tarRE$//i; - $info->{module} =~ s/-/::/g; } + $info->{module} =~ s/-/::/g; ($info->{name} = $info->{module}) =~ s/::/-/g unless $info->{name}; $info->{tarball} = $info->{name} if -d $info->{dist}; Кстати, Ваш патч несколько избыточен. Например: $ cat cpan2rpm-2.027-alt.patch|grep %perl_vendor +%perl_vendor_build +%perl_vendor_install +%perl_vendor_privlib/* +%perl_vendor_man3dir/* %perl_vendor_man3dir/* %perl_vendor_install +rm -rf %buildroot%perl_vendor_man3dir/ -%perl_vendor_privlib/* -%perl_vendor_man3dir/*
Закрываю задачи для Branch 5.
