# Ошибки сборки пакетов RPM

## <span class="mw-headline" id="bkmrk-error%3A-installed-%28bu-1">error: Installed (but unpackaged) file(s) found</span>

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

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

- файлы в директориях <span style="font-family: courier; color: #a0522d;">/usr/include</span>, <span style="font-family: courier; color: #a0522d;">/ust/lib(64)/pkgconfig</span>, добавляются в devel-пакеты
- файлы библиотек в директориях <span style="font-family: courier; color: #a0522d;">/lib(64)</span> и <span style="font-family: courier; color: #a0522d;">/usr/lib(64)</span>, оканчивающиеся на суффикс .so (например, <span style="font-family: courier; color: #a0522d;">libfoo.so</span>), также добавляются в devel-пакеты
- файлы библиотек в директориях <span style="font-family: courier; color: #a0522d;">/lib(64)</span> и <span style="font-family: courier; color: #a0522d;">/usr/lib(64)</span>, оканчивающиеся на цифру (например, <span style="font-family: courier; color: #a0522d;">libfoo.so.1</span>), добавляются в пакеты с соответсвующими библиотеками. Согласно правилам РОСЫ, каждая библиотека должна упаковываться в отдельный подпакет, соотевтсвующий ее имени и значению SONAME (как правило, это цифра после суффикса .so - так что файлы <span style="font-family: courier; color: #a0522d;">libfoo.so.1</span> и <span style="font-family: courier; color: #a0522d;">libfoo.so.1.2</span> должны находиться в пакете <span style="color: #343072; font-weight: bold;">lib(64)foo1</span>). Часто ошибка "Installed but unpackaged files found) в пакетах с библиотеками вызвана изменением значения SONAME - например, вместо <span style="font-family: courier; color: #a0522d;">libfoo.so.1</span> в новой версии пакета появился файл <span style="font-family: courier; color: #a0522d;">libfoo.so.2</span>. В этом случае вы также дополнительно увидите ошибку "Cannot find file or directory", сообщающую, что отсутсвует файл <span style="font-family: courier; color: #a0522d;">libfoo.so.1</span>. Для исправления сборки в такой ситуации достаточно изменить значение макроса major в начале spec-файла:

```
%define major 2
```

Помните, что при добавлении файлов в секции <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">%files</span> принято заменять некоторые стандартные пути макросами (например вместо <span style="font-family: courier; color: #a0522d;">/usr/lib</span> и <span style="font-family: courier; color: #a0522d;">/usr/lib64</span> необходимо использовать макрос <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">%{\_libdir</span>}, вместо <span style="font-family: courier; color: #a0522d;">/usr/share/man</span> - <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">%{\_mandir</span>} и так далее). Более полный список можно посмотреть с [скрипте из Updates Builder](https://abf.rosalinux.ru/dsilakov/updates_builder_launcher/blob/master/dir_to_macro.pm).

## <span class="mw-headline" id="bkmrk-file-not-found-1">File not found</span>

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

- в новой версии действительно нет таких файлов - в этом случае надо просто убрать их описание из секции <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">%files</span>
- в новой версии файлы переименованы либо перемещены в другое место. В этом случае вы также увидите ошибку "Installed (but unpackaged) file(s) found", как в случае с библиотеками (см. выше). В случае с библиотеками для исправления сразу обеих ошибок необходимо изменить значение переменной major в начале spec-файла. В общем же случае необходимо исправить секцию <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">%files</span>, чтобы она соответсвовала новым реалиям.
- отсутсвующие файлы собираются или не собираются в зависимости от параметров окружения и сборки - опций компиляции или установленных в сборочной среде пакетов (описанных в BuildRequires). Возможно, в новой версии пакета надо использовать какие-то новые опции сборки либо добавить дополнительные сборочные зависимости для получения этих файлов. Выявить такие ситуации можно на основе анализа журналов сборки и вывода команд наподобие configure или cmake, которые сообщают, какие опцилнальные возможности будут включены при сборке, а какие - нет. Например, <span style="color: #343072; font-weight: bold;">squid</span> может собираться с поддержкой аутентификации SASL и без нее. В первом случае в пакете будет присутсвовать файл basic\_sasl\_auth, во втором его не будет. Для ключения/отключения SASL необходимо добавить/удалить значение SASL из параметра --enable-auth-basic команды <span style="margin: 0 2px; color: #7a1869; padding: 0 5px; white-space: pre-line; word-wrap: break-word; border: 1px solid #EAEAEA; background-color: #f8f8f8; border-radius: 3px;">configure</span>, а также добавить сборочную зависимость (BuildRequires) от <span style="color: #343072; font-weight: bold;">sasl-devel</span>.

Помните, что при добавлении файлов в секции <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">%files</span> принято заменять некоторые стандартные пути макросами, а также что при описании файлов в секции <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">%files</span> могут использоваться символы '?' и '\*' (означающие один произвольный символ и любое количество произвольных символов соответсвенно).

## <span class="mw-headline" id="bkmrk-cp%3A-cannot-stat-%27%3Cso-1">cp: cannot stat '&lt;some\_file&gt;': No such file or directory</span>

Ошибка означает, что rpmbuild не смог найти файл &lt;some\_file&gt;, помеченный как <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">%doc</span> в секции %files вашего пакета. Возможно, этот файл был переименован (в этом случе вы также увидите ошибку "Installed (but unpackaged) file(s) found") - в этом случае надо изменить имя файла на новое (например, <span style="font-family: courier; color: #a0522d;">README</span> могут переименовать в <span style="font-family: courier; color: #a0522d;">README.md</span>). Если неупакованного файла с близким именем не появилось, то значит старый файл в новой версии отсутсвует и его определение в <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">%doc</span> необходимо просто удалить.

## <span class="mw-headline" id="bkmrk-reversed-%28or-previou-1">Reversed (or previously applied) patch detected</span>

Ошибка означает, что применявшийся к старой версии пакета патч по крайней мере частично уже применен в новой версии. Обратите внимание, что команда <span style="margin: 0 2px; color: #7a1869; padding: 0 5px; white-space: pre-line; word-wrap: break-word; border: 1px solid #EAEAEA; background-color: #f8f8f8; border-radius: 3px;">patch</span> делает такой вывод на основе попытки применить только первую часть патча! Если патч сложный и затрагивает несколько файлов или несколько мест одного файла, то необходимо вручную проверить, какие из этих изменений уже есть в новой версии, а каких нет. Для этого можно попробовать применить патч к новой версии вручную, отвечая "n" на вопрос "Assume '-R'" и "y" на предложени продолжить применять остальные части патча.

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

## <span class="mw-headline" id="bkmrk-%2Fvar%2Ftmp%2Frpm-tmp.xxx-1">/var/tmp/rpm-tmp.xxxxx: line yy: cd: &lt;some\_folder\_name&gt;: No such file or directory</span>

Ошибка означает, что rpmbuild не может определить, в какую директорию ему перейти после распаковки архива с исходным кодом. Имя директории указывается в опции <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">-n</span> макроса <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">%setup</span> в секции <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">%prep</span>. Если эта опция отсутсвует, то подразумевается использование "-n %{name}-%{version}". Для исправления ошибки необходимо посмотреть, как расположены файлы в новой версии архива с исходным кодом - обычно такой архив содержит директорию вида "&lt;имя\_программы&gt;-&lt;версия&gt;", но время от времени разработчики могут что-то изменять (например, переименовывать директорию просто в &lt;имя\_программы&gt;. Для исправления ошибки необходимо соответсвующим образом исправить значение опции "-n" макроса <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">%setup</span>.

## <span class="mw-headline" id="bkmrk-empty-debug-info-%D0%B8-d-1">empty-debug-info и debuginfo-without-sources</span>

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

- в пакете нет исполнимых файлов или библиотек. Если в пакете при этом вообще нет архитектурно-зависимых файлов (т.е. пакеты для разных архитектур имею абсолютно одинаковое содержимое), то необходимо объявить пакет как независимый от архитектуры, добавив в заголовок spec-файла декларацию "BuildArch: noarch". Если же архитектурно-зависимые файлы все-таки есть (например, какие-то данные могут быть специфичны для каждой арзитектуры; другой типичный пример - проприетарное приложение, которое уже поставляется в виде бинарных файлов бех отладочной информации), то необходимо отключить генерацию debug-пакетов, сбросив определение макроса <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">debug\_package</span> в начале spec-файла:

```
%define debug_package %{nil}
```

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

Остановимся подробнее на втором пункте. Большинство приложений позволяют настраивать передаваемые компилятору опции при старте сборки - например, при вызове <span style="font-family: courier; color: blue;">**configure**</span> или <span style="font-family: courier; color: blue;">**cmake**</span>. Для генерации отладочной информации для подобных приложений вам не нужно прилагать особых усилий - достаточно вместо прямого вызова <span style="font-family: courier; color: blue;">**configure**</span> или <span style="font-family: courier; color: blue;">**cmake**</span> использовать соответствующие макросы <span style="font-family: courier; color: blue;">**rpm**</span> (в нашем примере - <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">%configure2\_5x</span> или <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">%cmake</span> соответственно). Если использование макросов не помогает (либо в проекте не используются стандартные средства типа GNU Autotools или CMake), необходимо изучить схему сборки и посмотреть - нельзя ли на нее повлиять как-то еще - например, специфическими опциями либо переменными окружения. Типичными переменными, которые могут повлиять на сборку, являются <span style="font-style: italic; font-weight: bold; color: #ff3501;">CFLAGS</span>, <span style="font-style: italic; font-weight: bold; color: #ff3501;">CXXFLAGS</span> и <span style="font-style: italic; font-weight: bold; color: #ff3501;">CPPFLAGS</span>. Мы рекомендуем выставить эти переменные в макрос <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">%optflags</span>; при этом может оказаться необходимым перед использованием <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">%%optflags</span> вызвать макрос <span style="font-style: italic; font-weight: bold; color: #3e3e3e;">%%setup\_compile\_flag</span> (например так сделано в пакете \[[slock](https://abf.io/import/slock/commit/78a9ac338470558c7a38d1709ce6d9036e5bb408#diff-F2R24)\].

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

Бывают ситуации, когда повлиять на сборку извне нельзя никак - в скриптах сборки или файлах типа Makefile инструкции сборки "забиты" намертво. В таких случаях необходимо подготовить патч, добавляющий во все вызовы компилятора опцию <span style="font-style: italic; font-weight: bold; color: #ff3501;">-g</span>. Помимо опции <span style="font-style: italic; font-weight: bold; color: #ff3501;">-g</span> у компилятора, повлиять на отладочную информацию может компоновщик - например, его опции <span style="font-style: italic; font-weight: bold; color: #ff3501;">-s</span> и <span style="font-style: italic; font-weight: bold; color: #ff3501;">-S</span>, удаляющие подобные данные из результирующих бинарных файлов. Если такие опции явно передаются компоновщику в скриптах сборки либо файлах Makefile, то необходимо подготовить патч, убирающий их - например, так сделано в пакете \[[kicad](https://abf.io/import/kicad/commit/c93e3d9911e3b3be485ee5dd01cbea723a087729#diff-13)\].

## <span class="mw-headline" id="bkmrk-error%3A-can%27t-locate--1">Error: Can't locate Some/Perl/Module.pm in @INC</span>

Ошибка означает, что для сборки необходим Perl-модуль <span style="font-family: courier; color: #a0522d;">Some/Perl/Module.pm</span>, который не был обнаружен в сборочном окружении.

Для исправления ошибки необходимо добавить сборочную зависимость от такого модуля в 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.

## <span class="mw-headline" id="bkmrk-package%28s%29-suggested-1">Package(s) suggested but not available</span>

Данная ошибка может встречаться при сборке расширений языка 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

## <span class="mw-headline" id="bkmrk-error%3A-dependency%28ie-1">ERROR: dependency(ies) not available</span>

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

## <span class="mw-headline" id="bkmrk-hunk-failed----savin-1">hunk FAILED -- saving rejects</span>

Данная ошибка означает, что один из патчей (какой именно - указано в выводе 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 - это куски патчей, которые применить не удалось.

## <span class="mw-headline" id="bkmrk-package-%27foo%27-not-fo-1">package 'foo' not found</span>

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

## <span class="mw-headline" id="bkmrk-%22no-package-%27.%2A%27-fou-1">"No package '.\*' found"</span>

Такая ошибка возникает, если пакет проверяет необходимые сборочные зависимости с помощью <span style="margin: 0 2px; color: #7a1869; padding: 0 5px; white-space: pre-line; word-wrap: break-word; border: 1px solid #EAEAEA; background-color: #f8f8f8; border-radius: 3px;">pkgconfig</span> и не обнаруживает одну из них.

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

```
BuildRequires: pkgconfig(foo)
```

Предварительно необходимо убедиться, что такая зависимость может быть разрешена - попробовать ее установить с помощью <span style="margin: 0 2px; color: #7a1869; padding: 0 5px; white-space: pre-line; word-wrap: break-word; border: 1px solid #EAEAEA; background-color: #f8f8f8; border-radius: 3px;">urpmi</span>:

```
# urpmi 'pkgconfig(foo)'
```

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

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

## <span class="mw-headline" id="bkmrk-%2Fusr%2Fbin%2Fld%3A-cannot--1">/usr/bin/ld: cannot find -lfoo</span>

Данная ошибка возникает при линковке уже собранных объектных файлов и означает, что линкер не смог найти библиотеку "foo". Для исправления ошибки достаточно добавить зависимость от библиотеки в spec-файл. Чтобы определить, как именно эту зависимость прописать, необходимо сначала поискать devel-пакет для библиотеки <span style="color: #343072; font-weight: bold;">libfoo</span> (или <span style="color: #343072; font-weight: bold;">lib64foo</span> в 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.

## <span class="mw-headline" id="bkmrk-build.pl%3A-no-such-fi-1">Build.PL: No such file or directory</span>

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

- "/Build.PL installdirs=vendor" -&gt; "Makefile.PL INSTALLDIRS=vendor"
- ./Build install destdir=%{buildroot} -&gt; %makeinstall\_std
- perl Build.PL install destdir=%{buildroot} -&gt; %makeinstall\_std
- ./Build test -&gt; %make test
- ./Build -&gt; %make

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

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

## <span class="mw-headline" id="bkmrk-makefile.pl%3A-no-such-1">Makefile.PL: No such file or directory</span>

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

- "Makefile.PL INSTALLDIRS=vendor" -&gt; "./Build.PL installdirs=vendor"
- %makeinstall\_std -&gt; ./Build install destdir=%{buildroot}
- (если предыдущая замена не сработала) %makeinstall\_std -&gt; perl Build.PL install destdir=%{buildroot}
- %make test -&gt; ./Build test
- %make -&gt; ./Build

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

## <span class="mw-headline" id="bkmrk-fg%3A-no-job-control-1">fg: no job control</span>

Ошибка означает, что внутри spec-файла используется макрос RPM, не поддерживаемый в РОСЕ. Поддерживается или нет каждый конкретный макрос, можно узнать с помощью команды <span style="margin: 0 2px; color: #7a1869; padding: 0 5px; white-space: pre-line; word-wrap: break-word; border: 1px solid #EAEAEA; background-color: #f8f8f8; border-radius: 3px;">rpm --eval</span>:

```
$ rpm --eval %macro_name
```

Если <span style="font-family: courier; color: blue;">**rpm**</span> ничего не знает о таком макросе, то результатом выполнения этой команды будет "%macro\_name". В противном случае <span style="font-family: courier; color: blue;">**rpm**</span> развернет определение макроса.

## <span class="mw-headline" id="bkmrk-package-check-%22%2Fusr%2F-1">Package check "/usr/bin/rpmlint ..." failed</span>

Для проверки соблюдения политик сборки и оформления spec-файлов, в Росе используется утилита [Rpmlint](http://wiki.rosalab.ru/ru/index.php/Rpmlint "Rpmlint"). Многие ошибки этой утилиты некритичны, однако многие имеют "вес" (badness) и если суммарный вес ошибок для пакета больше или равен 50, то сборка завершается с ошибкой. Если это ваш случай - то первым делом необходимо поискать в логе ошибки, для которых светится "Badness: 50" и исправлять их. Перечень всех ошибок можно найти здесь: [Rpmlint Errors](http://wiki.rosalab.ru/ru/index.php/Rpmlint_Errors "Rpmlint Errors")

## Список используемых источников

- [Ошибки сборки пакетов RPM](http://wiki.rosalab.ru/ru/index.php/%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B8_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2_RPM#error:_Installed_.28but_unpackaged.29_file.28s.29_found)