Error installed but unpackaged file s found

В данной статье мы собрали несколько часто встречающихся при сборке пакетов RPM ошибок подобного рода и способы их исправления. Этот перечень создан на основе опыта прохождения практики студентами НИУ ВШЭ, но мы надеемся, что он пригодится не только им.

При сборке новых версий программ с помощью Updates Builder подобные ошибки исправляются автоматически (скриптом analyze_log.sh), так что можно использовать код этого скрипта как подсказку — что надо делать. Впрочем, скрипт не универсален и может не работать в каких-то специфических случаях.

error: Installed (but unpackaged) file(s) found

Ошибка означает, что в новой версии пакета появились новые файлы, отсутствующие ранее, и rpmbuild не знает, что с ними делать (и нужны ли ли вообще).

Если вы полагаете, что эти файлы нужны (а это так в 99.9% случаев), необходимо добавить их в секцию %files spec-файла. Если у вас есть несколько подпакетов, то надо сначала определить — к какому из них эти файлы относятся. Универсального рецепта здесь нет, однако есть несколько правил:

• файлы в директориях /usr/include, /ust/lib(64)/pkgconfig, добавляются в devel-пакеты
• файлы библиотек в директориях /lib(64) и /usr/lib(64), оканчивающиеся на суффикс .so (например, libfoo.so), также добавляются в devel-пакеты
• файлы библиотек в директориях /lib(64) и /usr/lib(64), оканчивающиеся на цифру (например, libfoo.so.1), добавляются в пакеты с соответсвующими библиотеками. Согласно правилам РОСЫ, каждая библиотека должна упаковываться в отдельный подпакет, соотевтсвующий ее имени и значению SONAME (как правило, это цифра после суффикса .so — так что файлы libfoo.so.1 и libfoo.so.1.2 должны находиться в пакете lib(64)foo1). Часто ошибка «Installed but unpackaged files found) в пакетах с библиотеками вызвана изменением значения SONAME — например, вместо libfoo.so.1 в новой версии пакета появился файл libfoo.so.2. В этом случае вы также дополнительно увидите ошибку «Cannot find file or directory», сообщающую, что отсутсвует файл libfoo.so.1. Для исправления сборки в такой ситуации достаточно изменить значение макроса major в начале spec-файла:

%define major 2

Помните, что при добавлении файлов в секции %files принято заменять некоторые стандартные пути макросами (например вместо /usr/lib и /usr/lib64 необходимо использовать макрос %{_libdir}, вместо /usr/share/man — %{_mandir} и так далее). Более полный список можно посмотреть с скрипте из Updates Builder.

File not found

Ошибка означает, что в новой версии пакета отсутсвуют некоторые файлы, присутствувавшие ранее. Причин для этого может быть несколько:

• в новой версии действительно нет таких файлов — в этом случае надо просто убрать их описание из секции %files
• в новой версии файлы переименованы либо перемещены в другое место. В этом случае вы также увидите ошибку «Installed (but unpackaged) file(s) found», как в случае с библиотеками (см. выше). В случае с библиотеками для исправления сразу обеих ошибок необходимо изменить значение переменной major в начале spec-файла. В общем же случае необходимо исправить секцию %files, чтобы она соответсвовала новым реалиям.
• отсутсвующие файлы собираются или не собираются в зависимости от параметров окружения и сборки — опций компиляции или установленных в сборочной среде пакетов (описанных в BuildRequires). Возможно, в новой версии пакета надо использовать какие-то новые опции сборки либо добавить дополнительные сборочные зависимости для получения этих файлов. Выявить такие ситуации можно на основе анализа журналов сборки и вывода команд наподобие configure или cmake, которые сообщают, какие опцилнальные возможности будут включены при сборке, а какие — нет. Например, squid может собираться с поддержкой аутентификации SASL и без нее. В первом случае в пакете будет присутсвовать файл basic_sasl_auth, во втором его не будет. Для ключения/отключения SASL необходимо добавить/удалить значение SASL из параметра —enable-auth-basic команды configure, а также добавить сборочную зависимость (BuildRequires) от sasl-devel.

Помните, что при добавлении файлов в секции %files принято заменять некоторые стандартные пути макросами, а также что при описании файлов в секции %files могут использоваться символы ‘?’ и ‘*’ (означающие один произвольный символ и любое количество
произвольных символов соответсвенно).

cp: cannot stat ‘<some_file>’: No such file or directory

Ошибка означает, что rpmbuild не смог найти файл <some_file>, помеченный как %doc в секции %files вашего пакета. Возможно, этот файл был переименован (в этом случе вы также увидите ошибку «Installed (but unpackaged) file(s) found») — в этом случае надо изменить имя файла на новое (например, README могут переименовать в README.md).
Если неупакованного файла с близким именем не появилось, то значит старый файл в новой версии отсутсвует и его определение в %doc необходимо просто удалить.

Reversed (or previously applied) patch detected

Ошибка означает, что применявшийся к старой версии пакета патч по крайней мере частично уже применен в новой версии. Обратите внимание, что команда patch делает такой вывод на основе попытки применить только первую часть патча! Если патч сложный и затрагивает несколько файлов или несколько мест одного файла, то необходимо вручную проверить, какие из этих изменений уже есть в новой версии, а каких нет. Для этого можно попробовать применить патч к новой версии вручную, отвечая «n» на вопрос «Assume ‘-R'» и «y» на предложени продолжить применять остальные части патча.

Если все изменения из патча действительно уже присутсвуют в новой версии, то патч можно спокойно удалить (физически из Git-репозитория, а также из spec-файла). Если же нет, то необходимо определить — нужны ли в новой версии оставшиеся изменения и если да, то переделать патч соответствующим образом. Такой анализ уже требует некоторых познаний в том, что именно делает патч.

/var/tmp/rpm-tmp.xxxxx: line yy: cd: <some_folder_name>: No such file or directory

Ошибка означает, что rpmbuild не может определить, в какую директорию ему перейти после распаковки архива с исходным кодом. Имя директории указывается в опции -n макроса %setup в секции %prep. Если эта опция отсутсвует, то подразумевается
использование «-n %{name}-%{version}». Для исправления ошибки необходимо посмотреть, как расположены файлы в новой версии архива с исходным кодом — обычно такой архив содержит директорию вида «<имя_программы>-<версия>», но время от времени разработчики могут что-то изменять (например, переименовывать директорию просто в <имя_программы>. Для исправления
ошибки необходимо соответсвующим образом исправить значение опции «-n» макроса %setup.

empty-debug-info и debuginfo-without-sources

Ошибки означают, что rpmbuild не смог должным образом сформировать подпакет с отладочной информацией. Две основные причины такого поведения:

• в пакете нет исполнимых файлов или библиотек. Если в пакете при этом вообще нет архитектурно-зависимых файлов (т.е. пакеты для разных архитектур имею абсолютно одинаковое содержимое), то необходимо объявить пакет как независимый от архитектуры, добавив в заголовок spec-файла декларацию «BuildArch: noarch». Если же архитектурно-зависимые файлы все-таки есть (например, какие-то данные могут быть специфичны для каждой арзитектуры; другой типичный пример — проприетарное приложение, которое уже поставляется в виде бинарных файлов бех отладочной информации), то необходимо отключить генерацию debug-пакетов, сбросив определение макроса debug_package в начале spec-файла:

%define debug_package %{nil}

• скрипты сборки приложения в пакете устроены таким образом, что сразу удаляют отладочную информацию из собранных файлов (например, явно вызывают команду strip либо просто не передают опцию «-g» компилятору). В таких случаях необходимо посмотреть, как заставить скрипты сборки оставить отладочную информацию. Иногда этого можно добиться с помощью переменных среды, а иногда может потребоваться патч, изменяющий сборочные скрипты. Если никакие способы не помогают, то можно отключить генерацию debug-пакетов, как описано выше, но делать так не рекомендуется — эти пакеты очень полезны для анализа ошибок в случае падений приложения.

Остановимся подробнее на втором пункте. Большинство приложений позволяют настраивать передаваемые компилятору опции при старте сборки — например, при вызове configure или cmake. Для генерации отладочной информации для подобных приложений вам не нужно прилагать особых усилий — достаточно вместо прямого вызова configure или cmake использовать соответствующие макросы rpm (в нашем примере — %configure2_5x или %cmake соответственно). Если использование макросов не помогает (либо в проекте не используются стандартные средства типа GNU Autotools или CMake), необходимо изучить схему сборки и посмотреть — нельзя ли на нее повлиять как-то еще — например, специфическими опциями либо переменными окружения. Типичными переменными, которые могут повлиять на сборку, являются CFLAGS, CXXFLAGS и CPPFLAGS. Мы рекомендуем выставить эти переменные в макрос %optflags; при этом может оказаться необходимым перед использованием %%optflags вызвать макрос %%setup_compile_flag (например так сделано в пакете [slock].

Обратите внимание на использование кавычек при выставлении переменных среды — они необходимы, поскольку макрос разворачивается в большой набор опций, разделенных пробелами.

Бывают ситуации, когда повлиять на сборку извне нельзя никак — в скриптах сборки или файлах типа Makefile инструкции сборки «забиты» намертво. В таких случаях необходимо подготовить патч, добавляющий во все вызовы компилятора опцию -g. Помимо опции -g у компилятора, повлиять на отладочную информацию может компоновщик — например, его опции -s и -S, удаляющие подобные данные из результирующих бинарных файлов. Если такие опции явно передаются компоновщику в скриптах сборки либо файлах Makefile, то необходимо подготовить патч, убирающий их — например, так сделано в пакете [kicad].

Error: Can’t locate Some/Perl/Module.pm in @INC

Ошибка означает, что для сборки необходим Perl-модуль Some/Perl/Module.pm, который не был обнаружен в сборочном окружении.

Для исправления ошибки необходимо добавить сборочную зависимость от такого модуля в spec-файл:

BuildRequires: perl(Some::Perl::Module)

Предварительно необходимо убедиться, что такой модуль вообще существует — попробовать его установить с помощью dnf (в rosa2019.1 и новее) либо urpmi (в rosa2016.1):

# dnf install 'perl(Some::Perl::Module)'

# urpmi 'perl(Some::Perl::Module)'

Если urpmi скажет, что не нашел нужного пакета, то необходимо сначала добавить пакет с модулем в репозитории РОСЫ.

Обратите внимание, что необходимый модуль может находиться в репозитории Contrib, в то время как вы собираете пакет в репозитории Main, Non-free или Restricted. В таком случае Contrib при сборке не используется и требуемый модуль необходимо перенести в репозиторий Main.

Package(s) suggested but not available

Данная ошибка может встречаться при сборке расширений языка R. Она означает, что у собираемого пакета есть необязательная зависимость от каких-то других модулей, которые в сборочной среде отсутствуют. В идеале для каждой такой зависимости необходимо прописать BuildRequires и Requires — например, если ошибка относится к модулю «foo», то нужны зависимости от R-foo:

BuildRequires: R-foo
Requires: R-foo

Предварительно необходимо убедиться, что такой пакет вообще есть в репозиториях — вывод команды «urpmq R-foo» должен быть непуст. Если пакета нет, то желательно его сначала собрать и добавить в репозитории. Однако при сборке может оказаться, что он зависит от того пакета, который вы собирали до этого и для которого вы собственно и хотите добавить зависимость R-foo. В этом случае первый пакет можно собрать и без R-foo, закомментировав при этом команду «%{_bindir}/R CMD check %{packname}» в секции %check. После этого можно будет уже собрать R-foo и вернуться к исходному пакету, добавив в него зависимость от R-foo и включив тесты в секции %check

ERROR: dependency(ies) not available

Данная ошибка также может встречаться при сборке расширений языка R, но в отличие от предыдущей, здесь речь идет об обязательных зависимостях сборки. Без них пакет не может быть собран, поэтому вам необходимо добавить в spec-файл соответсвующие BuildRequiers и Requires, а при необходимости предварительно собрать нужные пакеты в репозитории РОСЫ.

hunk FAILED — saving rejects

Данная ошибка означает, что один из патчей (какой именно — указано в выводе rpmbuild) не может быть применен без изменений к новой версии программы. Обычно это означает, что патч необходимо переделать (предварительно определив — нужен ли он еще), что требует определенной квалификации. Однако иногда такая ошибка возникает из-за «строгости» rpmbuild при применении патчей и проблемный патч может быть исправлен в автоматическом режиме с помощью утилиты rediff_patch.

Для этого достаточно склонировать себе Git-репозиторий, перейти в склонированную папку, поместить туда архив с исходным кодом новой версии и запустит rediff_patch, передав ей нужный патч к качестве аргумента:

$ abf get myrepo/myproject
$ cd myproject
$ wget http://project-upstream.org/new-version.tgz
$ rediff_patch <some_patch_to_rediff>

Если все сложится удачно, то радом со старым патчем «some_patch_to_rediff» появится новый — «some_patch_to_rediff.new» Если же что-то пойдет не так, то в текущей директории останутся папка «rediff_patch» с подпапками вида «myproject.orig» и «myproject» — содержащие соответсвенно оригинальный исходный код и исходный код, получившийся после попытки применить
патч. Во второй папке вы найдете файлы с расширениями *rej — это куски патчей, которые применить не удалось.

package ‘foo’ not found

Аналогична следующей ошибке

«No package ‘.*’ found»

Такая ошибка возникает, если пакет проверяет необходимые сборочные зависимости с помощью pkgconfig и не обнаруживает одну из них.

Для исправления ошибки достаточно добавить нужную зависимость сборки в spec-файл:

BuildRequires: pkgconfig(foo)

Предварительно необходимо убедиться, что такая зависимость может быть разрешена — попробовать ее установить с помощью urpmi:

# urpmi 'pkgconfig(foo)'

Если urpmi скажет, что не нашел нужного пакета, то необходимо сначала добавить пакет с соответсвующей библиотекой (как правило, она и называется libfoo) в репозитории РОСЫ.

Обратите внимание, что необходимый пакет может находиться в репозитории Contrib, в то время как вы собираете пакет в репозитории Main, Non-free или Restricted. В таком случае Contrib при сборке не используется и требуемый пакет необходимо перенести в репозиторий Main.

/usr/bin/ld: cannot find -lfoo

Данная ошибка возникает при линковке уже собранных объектных файлов и означает, что линкер не смог найти библиотеку «foo». Для исправления ошибки достаточно добавить зависимость от библиотеки в spec-файл. Чтобы определить, как именно эту зависимость прописать, необходимо сначала поискать devel-пакет для библиотеки libfoo (или lib64foo в 64битной системе) с помощью urpmq:

# urpmq -a libfoo
  lib64foo1
  lib64foo-devel

Интересующий нас пакет — тот, что оканчивается на -devel. Посмотрим, что он предоставляет:

# urpmq --provides libfoo-devel
  lib64foo-devel: devel(libfoo(64bit))
  lib64foo-devel: lib64sasl-devel[== 2.1.25]
  lib64foo-devel: libsasl-devel[== 2.1.25]
  lib64foo-devel: libfoo-devel[== 2.1.25]
  lib64foo-devel: sasl-devel[== 2.1.25-7]
  lib64foo-devel: lib64foo-devel[== 2.1.25-7:2014.1]
  lib64foo-devel: pkgconfig(foo)[== 2.1.25-7]

Из данного набора необходимо выбрать что-то одно. В РОСЕ отдается предпочтение зависимостям вида pkgconfig(…), так что в нашем примере в spec-файл необходимо добавить следующую строку:

BuildRequires: pkgconfig(foo)

Если pkgconfig(foo) не окажется в выводе urpmq, то надо добавить зависимость от foo-devel, а если и ее нет — то от libfoo-devel.

Build.PL: No such file or directory

Такая ошибка означает, что предыдущая версия пакета собиралась с помощью скрипт Build.PL, отсутсвующего в новой версии. Часто встречающаяся ситуация — замена Build.PL на Makefile.PL. Если в архиве с исходным кодом новой версии есть скрипт Makefile.PL, то в spec-файле необходимо произвести следующие замены:

• «/Build.PL installdirs=vendor» -> «Makefile.PL INSTALLDIRS=vendor»
• ./Build install destdir=%{buildroot} -> %makeinstall_std
• perl Build.PL install destdir=%{buildroot} -> %makeinstall_std
• ./Build test -> %make test
• ./Build -> %make

Для примера можно посмотреть на пакет …

Если же скрипта Makefile.PL в новой версии также нет, то необходимо смотреть — а что, собственно, есть — файлы CMake, configure или готовый Makefile и модифицировать spec-файл в соответствии с используемой системой сборки.

Makefile.PL: No such file or directory

Возможна и обратная ситуация — вместо Makefile.PL разработчики перешли на Build.PL или что-то еще. Если в архиве с новым исходным кодом есть файл Build.PL, то необходимо провести в spec-файле замены, обратные приведенным в предыдущем пункте:

• «Makefile.PL INSTALLDIRS=vendor» -> «./Build.PL installdirs=vendor»
•  %makeinstall_std -> ./Build install destdir=%{buildroot}
• (если предыдущая замена не сработала) %makeinstall_std -> perl Build.PL install destdir=%{buildroot}
•  %make test -> ./Build test
•  %make -> ./Build

Если же скрипта Build.PL в новой версии также нет, то необходимо смотреть — а что, собственно, есть — файлы CMake, configure или готовый Makefile и модифицировать spec-файл в соответствии с используемой системой сборки.

fg: no job control

Ошибка означает, что внутри spec-файла используется макрос RPM, не поддерживаемый в РОСЕ. Поддерживается или нет каждый конкретный макрос, можно узнать с помощью команды rpm —eval:

$ rpm --eval %macro_name

Если rpm ничего не знает о таком макросе, то результатом выполнения этой команды будет «%macro_name». В противном случае rpm развернет определение макроса.

Package check «/usr/bin/rpmlint …» failed

Для проверки соблюдения политик сборки и оформления spec-файлов, в Росе используется утилита Rpmlint. Многие ошибки этой утилиты некритичны, однако многие имеют «вес» (badness) и если суммарный вес ошибок для пакета больше или равен 50, то сборка завершается с ошибкой. Если это ваш случай — то первым делом необходимо поискать в логе ошибки, для которых светится «Badness: 50» и исправлять их. Перечень всех ошибок можно найти здесь: Rpmlint Errors

I looked around but none of the answers to this same error message worked in my simple package… I am building the rpm using rpmbuild on Redhat ES 6 and no matter what I have done in my spec file I get the same results. Thank you in advance for your help.

Here is my spec file:

Name:  package
Version: 3.2.5
Release: redhat
Summary: Company package gateway pos server

Group:  Engineering
License: Company LLC - owned
URL:    http://www.company.com
Source: %{name}.tar.gz

%description
The Company package gateway server provides a key component in the Company system      architecture which passes information between the clients and the API.

%prep
%setup -n %{name}

%build

%define debug_package %{nil}

%install
mkdir -p $RPM_BUILD_ROOT/srv/package/gateways/config
mkdir -p $RPM_BUILD_ROOT/srv/package/gateways/logs

install -m 700 gateway $RPM_BUILD_ROOT/srv/package/
install -m 700 gatewayclient.conf $RPM_BUILD_ROOT/srv/package/
install -m 700 gateway.conf $RPM_BUILD_ROOT/srv/package/
install -m 700 rules.conf $RPM_BUILD_ROOT/srv/package/
install -m 700 gatewaytest.conf $RPM_BUILD_ROOT/srv/package/
install -m 700 gateways/bci.exe $RPM_BUILD_ROOT/srv/package/gateways/
install -m 700 gateways/config/bci_iso8583.conf $RPM_BUILD_ROOT/srv/package/gateways/config/

%post

%clean
rm -rf %{buildroot}
rm -rf $RPM_BUILD_ROOT
rm -rf %{_tmppath/%{name}
rm -rf %{_topdir}/BUILD%{name}

%files -f %{name}.lang
%defattr(-,root,root,-)

/srv/
/srv/package/
/srv/package/gateways/
/srv/package/gateways/logs/
/srv/package/gateways/config/
/srv/package/gateway
/srv/package/gatewayclient.conf
/srv/package/gateway.conf
/srv/package/gatewaytest.conf
/srv/package/rules.conf
/srv/package/gateways/bci.exe
/srv/package/gateways/config/bci_iso8583.conf

%changelog
* Thurs May 09 2013 Owner
- 1.0 r1 First release

The error message is here:

Checking for unpackaged file(s): /usr/lib/rpm/check-files     /home/rpmbuild/rpmbuild/BUILDROOT/package-3.2.5-redhat.x86_64
error: Installed (but unpackaged) file(s) found:
   /srv/package/gateways/bci.exe
   /srv/package/gateways/config/bci_iso8583.conf
   /srv/package/gateway
   /srv/package/gateway.conf
   /srv/package/gatewayclient.conf
   /srv/package/gatewaytest.conf
   /srv/package/rules.conf


RPM build errors:
   Installed (but unpackaged) file(s) found:
   /srv/package/gateways/bci.exe
   /srv/package/gateways/config/bci_iso8583.conf
   /srv/package/gateway
   /srv/package/gateway.conf
   /srv/package/gatewayclient.conf
   /srv/package/gatewaytest.conf
   /srv/package/rules.conf

Edition — Reran with suggestions below and got these results:

Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/rpmbuild/rpmbuild/BUILDROOT/package-3.2.5-redhat.x86_64
error: Installed (but unpackaged) file(s) found:
   /srv/package/gateways/bci.exe
   /srv/package/gateways/config/bci_iso8583.conf
   /srv/package/gateway
   /srv/package/gateway.conf
   /srv/package/gatewayclient.conf
   /srv/package/gatewaytest.conf
   /srv/package/rules.conf


RPM build errors:
    Installed (but unpackaged) file(s) found:
   /srv/package/gateways/bci.exe
   /srv/package/gateways/config/bci_iso8583.conf
   /srv/package/gateway
   /srv/package/gateway.conf
   /srv/package/gatewayclient.conf
   /srv/package/gatewaytest.conf
   /srv/package/rules.conf

Решено: проблема сборки RPM (Installed (but unpackaged) file(s) found:)

Модератор: Bizdelnick

Trying to package up wget-1.13.tar.gz into a rpm (I am re-learning this process) and I’m running into these errors when I do a dry run.

error: Installed (but unpackaged) file(s) found:
/etc/wgetrc
/usr/bin/wget
/usr/share/info/dir
/usr/share/info/wget.info.gz
/usr/share/locale/be/LC_MESSAGES/wget.mo
RPM build errors:
Installed (but unpackaged) file(s) found:
/etc/wgetrc
/usr/bin/wget
/usr/share/info/dir
/usr/share/info/wget.info.gz
/usr/share/locale/be/LC_MESSAGES/wget.mo
/usr/share/locale/bg/LC_MESSAGES/wget.mo
/usr/share/locale/ca/LC_MESSAGES/wget.mo

There are more paths it complains about so this just a snippet but you should get the idea.

My Spec file is as follows:

Name:       wget
Version:    1.13    
Release:    1%{?dist}
Summary:    wget to get wget things

Group:      System Environment/Base
License:    GPL
#URL:       
Source0:    %{name}-%{version}.tar.gz
BuildRoot:  /tmp/%{name}-%{version}-%{release}-root 

#BuildRequires: 
#Requires:  

%description
Wget is a free software package for retrieving files using HTTP, HTTPS ... GNU   Wget        has many features to make retrieving large files

%prep
%setup -q


%build
%configure
make %{?_smp_mflags}


%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT


%clean
rm -rf $RPM_BUILD_ROOT


%files
%defattr(-,root,root,-)
%doc



%changelog

So a basic spec file, where am I going wrong?

Also, the file structure my RPMS is $HOME/rpms/{BUILD,RPMS,SOURCES,SPECS,SRPMS}

Thanks

# RPM package configuration

[package.metadata.rpm]
package = "fog05-agent"

[package.metadata.rpm.cargo]
buildflags = ["--release"]

[package.metadata.rpm.targets]
fog05-agent = { path = "/usr/bin/fog05-agent" }

[package.metadata.rpm.files]
"../etc/agent.yaml" = { path = "/etc/fos/agent.yaml", mode = "644", username = "fos" }
"../var/placeholder" = { path = "/var/fos/placeholder", username = "fos" }
"../resources/fos-agent.service" = { path = "/lib/systemd/system/fos-agent.service" }

%define __spec_install_post %{nil}
%define __os_install_post %{_dbpath}/brp-compress
%define debug_package %{nil}

Name: fog05-agent
Summary: fog05: The End-to-End Compute, Storage and Networking Virtualisation solution.
Version: @@VERSION@@
Release: @@RELEASE@@%{?dist}
License:  EPL-2.0 OR Apache-2.0
Group: Applications/System
Source0: %{name}-%{version}.tar.gz
URL: http://fog05.io

BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root

%description
%{summary}

%prep
%setup -q

%install
rm -rf %{buildroot}
mkdir -p %{buildroot}
cp -a * %{buildroot}

%clean
rm -rf %{buildroot}

%files
%defattr(-,root,root,-)
%{_bindir}/*

Recently I’ve been compiling several Perl modules for installation on new CentOS 7 machines because we’ll be using it to deploy several Catalyst and Mojolicious applications.

The tools

I’ve mainly used the following tools

• cpanspec — generates spec files for Perl modules from CPAN available through yum in epel repos:

  sudo yum install cpanspec

• rpmbuild — build rpm packages, available in rpm-based systems

The cycle

cpanspec -v --packager "My Packager Name" GD::SecurityImage
mv *.spec rpmbuild/SPECS/.; mv *.tar.gz rpmbuild/SOURCES/.
rpmbuild -ba rpmbuild/SPECS/perl-GD-SecurityImage.spec

Common issues — and work-arounds

My main purpose in writing this post was to compile and share the most common issues I ran into while building RPMs from CPAN modules. Hope this helps you and probably my future-self.

Modules using Module::Build::Tiny

(solved in cpanspec master with Leon’s PR) CPAN modules that use Module::Build::Tiny instead of the most commonly used Module::Build present the following error:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ERROR: Can't create '/usr/local/share/man/man3'
Do not have write permissions on '/usr/local/share/man/man3'
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 at /usr/local/share/perl5/Module/Build/Tiny.pm line 119.

(if you don’t, I’d guess you’re building the modules with root, which can get you in a lot of trouble)

This is caused by the lack of support by the Tiny module of all the types of arguments available in Module::Build (this is not really a bug but a design option). The arguments passed should have the -- prefix (check Leon’s comment on the subject), so, the solution is to edit the spec file and in the sections %build and %install fix the arguments:

--installdirs
--destdir
--create_packlist

Now you can run rpmbuild and everything should be fine.

Packages hidden from PAUSE

For some reason (please tell me why) many distributions hide some namespaces from PAUSE (Perl Authors Upload Server) — HTML::FormHandler example. This causes yum to fail on install, which is quite unpleasant.

Error: Package: perl-HTML-FormHandler-0.40059-1.el7.centos.noarch (/perl-HTML-FormHandler-0.40059-1.el7.centos.noarch)
           Requires: perl(HTML::FormHandler::Meta::Role)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

A side-effect of hiding the namespace from PAUSE was that neither cpanspec or rpmbuild was able to identify that the HTML::FormHandler::Meta::Role was provided by that same module and listed it as a dependency. You could just add AutoReq: no after the remaining Requires in the spec file but I find that a better work-around is to add:

Provides:       perl(HTML::FormHandler::Meta::Role)

so that rpmbuild and remaining tools now know that this module already has that class. rpmbuild/SPECS/perl-HTML-FormHandler.spec -> Provides

Missing files in MANIFEST — Installed (but unpackaged) file(s) found

Some packages just don’t include all the files that they provide (e.g. Test::Harness):

error: Installed (but unpackaged) file(s) found:
   /usr/bin/prove
   /usr/share/man/man1/prove.1.gz

The solution is simple: just double-check that nothing out of the ordinary is there and add the list to the %files spec section. Just copy & paste — that easy.

Bogus paths

Not all module packages are created equal, and some of them, are bogus…

BOGUS PATH DETECTED: PDF-Table-Version_0.9.7/
...
Skipping PDF-Table-0.9.7.tar.gz with 24 path elements!

To fix this issue you’ll need to re-package the module but it should be rather easy:

mkdir tmp
cd tmp/
tar xzvf ../PDF-Table-0.9.7.tar.gz
mv PDF-Table-Version_0.9.7/ PDF-Table-0.9.7/
tar czvf PDF-Table-0.9.7.tar.gz PDF-Table-0.9.7
cp PDF-Table-0.9.7.tar.gz ../
cd ..
cpanspec PDF-Table-0.9.7.tar.gz

Now you’ll be able to successfully create your .spec file and continue building that module.

Polluted environment — File not found

An error that got me spinning around for hours occurred when rpmbuild could not find some build files, around the lines of:

RPM build errors:
 File not found by glob

I think this is caused by CPAN it might alter your environment with something similar to:

PERL_MM_OPT=INSTALL_BASE=/home/rpmbuild/perl5

As a work-around it’s possible to just unset the constant:

unset PERL_LOCAL_LIB_ROOT
unset PERL_MM_OPT
unset INSTALL_BASE
unset PERL_MB_OPT

See also

• http://www.openfusion.net/linux/openfusion_rpm_repository — Repositories with several pre-built CPAN modules
• http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-auto-depend.html
• https://fedoraproject.org/wiki/Perl/Tips?rd=PackagingTips/Perl#Makefile.PL_vs_Build.PL

Changelog

• Thanks to Thibault for PERL_MB_OPT

Иногда бывает, что на поиск нужной RPM-ки уходит времени больше, чем на создание своей из исходников. Например, RPM-пакет pptpd 1.3.4 более недоступен по ссылке, которая была в посте об установке pptpd. А мне он как раз понадобился при настройке очередного VPN-сервера. Выход как всегда есть. Рассмотрим на примере pptpd создание rpm-пакета на основе исходных текстов, запакованных в классический tarball с раширением .tar.gz.

1. Качаем tarball отсюда: http://sourceforge.net/projects/poptop/files/
2. Устанавливаем пакет rpm-build:

   [root@server]# yum install rpm-build
   Setting up Install Process
   Resolving Dependencies
   --> Running transaction check
   ---> Package rpm-build.i386 0:4.4.2.3-20.el5_5.1 set to be updated
   --> Processing Dependency: elfutils for package: rpm-build
   --> Running transaction check
   ---> Package elfutils.i386 0:0.137-3.el5 set to be updated
   --> Processing Dependency: elfutils-libs-i386 = 0.137-3.el5 for package: elfutils
   --> Processing Dependency: libdw.so.1(ELFUTILS_0.127) for package: elfutils
   --> Processing Dependency: libdw.so.1(ELFUTILS_0.122) for package: elfutils
   --> Processing Dependency: libasm.so.1 for package: elfutils
   --> Processing Dependency: libdw.so.1(ELFUTILS_0.130) for package: elfutils
   --> Processing Dependency: libdw.so.1 for package: elfutils
   --> Processing Dependency: libasm.so.1(ELFUTILS_1.0) for package: elfutils
   --> Processing Dependency: libdw.so.1(ELFUTILS_0.126) for package: elfutils
   --> Running transaction check
   ---> Package elfutils-libs.i386 0:0.137-3.el5 set to be updated
   --> Finished Dependency Resolution
   Dependencies Resolved
   ===================================================================
    Package     Arch    Version         Repository  Size
   ===================================================================
   Installing:
    rpm-build      i386   4.4.2.3-20.el5_5.1   updates    302 k
   Installing for dependencies:
    elfutils       i386   0.137-3.el5          base       228 k
    elfutils-libs  i386   0.137-3.el5          base       193 k
   Transaction Summary
   ===================================================================
   Install       3 Package(s)
   Upgrade       0 Package(s)
    
   Total download size: 723 k
   Is this ok [y/N]: y
   Downloading Packages:
   (1/3): elfutils-libs-0.137-3.el5.i386.rpm               | 193 kB   00:00
   (2/3): elfutils-0.137-3.el5.i386.rpm                    | 228 kB   00:00
   (3/3): rpm-build-4.4.2.3-20.el5_5.1.i386.rpm            | 302 kB   00:00
    
   Total                                            842 kB/s | 723 kB 00:00
   Running rpm_check_debug
   Running Transaction Test
   Finished Transaction Test
   Transaction Test Succeeded
   Running Transaction
     Installing     : elfutils-libs                                1/3
     Installing     : elfutils                                     2/3
     Installing     : rpm-build                                    3/3
   Installed:
     rpm-build.i386 0:4.4.2.3-20.el5_5.1
   Dependency Installed:
     elfutils.i386 0:0.137-3.el5  elfutils-libs.i386 0:0.137-3.el5
   Complete!

   Возможно, также еще потребуется С-компилятор, такой как gcc (если еще не установлен).

3. Собираем пакет:

   [root@server]# rpmbuild -tb /tmp/pptpd-1.3.4.tar.gz

4. Находим вновьсозданную rpm-ку:

   [root@server]# ls -l /usr/src/redhat/RPMS/i386/
   -rw-r--r-- 1 root root 84570 Nov  5 22:18 pptpd-1.3.4-1.i386.rpm

5. Устанавливаем:

   [root@server]# rpm -ivh /usr/src/redhat/RPMS/i386/pptpd-1.3.4-1.i386.rpm

Если пакет собирается обычным юзером, не обладающим привилегиями суперпользователя, то доступа на запись в директорию /usr/src/redhat у него, ясное дело, нет. В этой ситуации можно явно указать rpmbuild-у рабочие директории следующим образом:

WD=$HOME/tmp/rpmtop
[ ! -d $WD ] && mkdir -p $WD
mkdir -p $WD/{SOURCES,BUILD,SPECS,SRPMS,RPMS/`uname -m`}
echo "%_topdir $WD" >> $HOME/.rpmmacros

Во 3-ей строке команда «uname -m» вернёт конкретную, используемую Вами архитектуру. В большинстве случаев это “i386”. У меня — “x86_64”.

Можно также собирать rpm-пакет из src.rpm. Например, мне как-то нужно было поставить на кучу серверов сразу с CentOS x86_64 пакет tinyproxy. В том пакете, который мне удалось найти в известных мне репозиториях (EPEL, RPMForge), был кривой init-скрипт, в котором был неправильно указан путь к бинарнику (/usr/bin/tinyproxy вместо /usr/sbin/tinyproxy) и путь к pid-файлу, что приводило к невозможности запустить сервис штатными средствами без доработки напильником стартового скрипта /etc/init.d/tinyproxy на каждом сервере. К тому же, конфиг-файл по умолчанию меня несколько не устраивал, поэтому я решил всё это один раз подредактировать и создать свою RPM-ку, которую потом простым скриптом можно было сразу проинсталлировать на все сервера. Далее я нашёл tinyproxy-1.8.2-1.fc14.src.rpm и распаковал его:

# rpm2cpio < tinyproxy-1.8.2-1.fc14.src.rpm | cpio -i
430 blocks
# ls -la
total 488
drwxrwxr-x  2 avz avz   4096 Apr 13 13:13 .
drwx------ 10 avz avz   4096 Apr 13 13:13 ..
-rw-r--r--  1 avz avz 214619 Apr 12 14:51 tinyproxy-1.8.2-1.fc14.src.rpm
-rw-rw-r--  1 avz avz 202931 Apr 13 13:13 tinyproxy-1.8.2.tar.bz2
-rw-r--r--  1 avz avz  10147 Apr 13 13:13 tinyproxy.conf
-rw-r--r--  1 avz avz   1906 Apr 13 13:13 tinyproxy.init
-rw-r--r--  1 avz avz    252 Apr 13 13:13 tinyproxy.logrotate
-rw-r--r--  1 avz avz   4109 Apr 13 13:13 tinyproxy.spec

Теперь редактируем файлы tinyproxy.init и tinyproxy.conf (при необходимости). В файл tinyproxy.spec в раздел changelog пишем чего же мы такого ценного привнесли своими изменениями (это необязательно, просто правило хорошего тона) и собственно собираем rpm-ку:

# mv tinyproxy-1.8.2.tar.bz2 tinyproxy.conf tinyproxy.init tinyproxy.logrotate /usr/src/redhat/SOURCES
# rpmbuild -ba tinyproxy.spec

Если всё прошло успешно (нет ошибок от make), то сможем наблюдать появление правильной RPM-ки, которую и можно ставить на все сервера сразу:

# ls /usr/src/redhat/RPMS/`uname -m`/tin*
/usr/src/redhat/RPMS/x86_64/tinyproxy-1.8.2-1.x86_64.rpm

Ключик -ba, кстати, также создаёт и src.rpm в директории /usr/src/redhat/SRPMS — может пригодиться при последующих пересборках. Если же make выдаёт ошибки, то надо разбираться и чинить. В моём случае, например, пришлось установить пакет docbook-style-xsl, потому что без него man-файлы почему-то не создавались в процессе сборки.