Частые проблемы rpmlint

Это сборник информации по работе с rpmlint. Обратите внимание, что первое, что вам следует сделать, — использовать опцию -e для rpmlint, чтобы получить дополнительный пояснительный текст. Например:

rpmlint -e description-line-too-long

description-line-too-long:
Строки вашего описания не должны превышать 80 символов. Если строка
превышает это число, разделите её на две строки.

Предоставленная здесь информация не является исчерпывающей. Она охватывает некоторые сценарии, для которых известны быстрые исправления. Это также не «панацея» для каждого сценария, и её следует тщательно рассматривать в контексте сборки вашего RPM. Некоторые предупреждения rpmlint не должны исправляться для некоторых пакетов, например, предупреждения о нестандартных группах или пользователях или о setuid-исполняемых файлах могут быть абсолютно правильными для некоторых пакетов. Вы можете увидеть описания различных проблем rpmlint в файлах, устанавливаемых пакетом rpmlint в /usr/lib/python3.12/site-packages/rpmlint/descriptions/.

Для получения дополнительной информации о проекте rpmlint обратитесь к проекту Rpmlint на GitHub.

debuginfo-without-sources

rpmlint -e debuginfo-without-sources даёт хорошее общее представление. См. также Флаги компилятора. Для исправления убедитесь, что создаются отладочные символы и что они не удаляются, чтобы они были доступны для постобработки rpmbuild.

file-not-utf8

Указывает, что текстовая кодировка указанного файла, обычно файла документации, не является UTF-8.

  • Обычно исправляется запуском iconv для несжатого файла перед установкой. См. man-страницу ICONV(1). Например, чтобы перекодировать файл с именем AUTHORS, закодированный в latin-1, вы можете использовать:

iconv -f iso8859-1 -t utf-8 AUTHORS > AUTHORS.conv && mv -f AUTHORS.conv AUTHORS

или ознакомьтесь с примером на странице советов по упаковке Perl и странице общих хитростей.

hardcoded-library-path

  • Не прописывайте путь жёстко в SPEC. Используйте макросы.

incorrect-fsf-address

  • Во всех случаях о проблеме следует уведомить вышестоящий проект. Это единственное требование в отношении этой ошибки.

Файл лицензии, обычно COPYING, не должен изменяться по юридическим причинам. Другие файлы могут быть изменены, если это сочтено целесообразным.

incoherent-version-in-changelog

invalid-license

Значение тега License не распознано.

invalid-soname

Обработка этой ошибки зависит от пути загрузки ld.so ("пути компоновщика") и того, относится ли он к частной или публичной библиотеке.

Путь компоновщика — это %{_libdir} + любой путь, указанный в /etc/ld.so.conf или в файле в /etc/ld.so.conf.d.

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

У нас есть четыре случая:

  • Библиотека публичная. Сообщите вышестоящему проекту о проблеме и предложите добавить или исправить управление версиями, возможно, отправив патч. Не применяйте патч, пока он не будет принят вышестоящим проектом, чтобы избежать проблем с обновлением.

  • Библиотека хранится вне пути компоновщика. В этом случае ошибку можно игнорировать.

  • Библиотека частная и хранится в каталоге, включённом в путь компоновщика. Если возможно, переместите библиотеку в другой каталог вне пути компоновщика. Это может потребовать изменения скриптов сборки.

  • Библиотека частная, хранится в каталоге, включённом в путь компоновщика, и не может быть перемещена. В этом случае библиотека должна иметь имя, которое вряд ли будет конфликтовать с другими библиотеками. Рассмотрите возможность фильтрации Provides, чтобы убедиться, что частная библиотека не видна.

Стандартный способ перемещения частной библиотеки — создать новый каталог в %{_libdir}, например, /usr/lib/myapp. Не добавляйте его в файлы /etc/ld.so.conf! Вместо этого используйте rpath, чтобы приложение могло найти библиотеку.

См. также:

no-binary

Пакет должен быть архитектуры noarch, поскольку он не содержит двоичных файлов.

  • Добавьте BuildArch: noarch в SPEC-файл

no-documentation

Указывает, что rpmlint не смог найти файлы, помеченные как %doc. Есть несколько случаев, когда это допустимо:

  • Пакет действительно не имеет документации. Это редкость и в целом довольно плохая идея; каждый пакет должен иметь какую-либо документацию и должен иметь хотя бы текст своей лицензии. Однако некоторые пакеты имеют внутренние справочные системы.

  • Вся документация была включена в подпакет -doc. Это было бы редкостью, поскольку большинство пакетов должны иметь текст лицензии, журнал изменений или другую информацию, которую лучше поместить в основной пакет, а не в подпакет -doc.

  • Это подпакет, а соответствующая документация была включена в основной пакет. Это часто происходит с подпакетом -devel, но вы должны как минимум перепроверить, чтобы убедиться, что вся документация пакета, предназначенная для разработчиков, включена в подпакет -devel.

no-soname

Указывает, что указанная общая библиотека не имеет soname (поле DT_SONAME ELF). Если исполняемый файл слинкован с общим объектом, который имеет поле DT_SONAME, при запуске исполняемого файла динамический компоновщик попытается загрузить общий объект, указанный в поле DT_SONAME, вместо использования имени файла, переданного компоновщику. См. man-страницу LD(1).

См. также:

private-shared-object-provides

W: python-dulwich.x86_64: W: private-shared-object-provides /usr/lib64/python2.6/site-packages/dulwich/_objects.so _objects.so()(64bit)

script-without-shebang

  • Вы забыли снять биты выполнения с файлов, о которых сообщает эта ошибка. См. также: добавить shebang.

spurious-executable-perm

Указывает, что у файла установлен бит выполнения, хотя, вероятно, его быть не должно.

  • Снимите бит выполнения, например chmod -x README.md в разделе %install вашего spec-файла.

standard-dir-owned-by-package

Этот пакет владеет каталогом, который является частью стандартной иерархии, что может привести к изменению прав доступа или владельцев по умолчанию на что-то нестандартное.

  • Вы не должны делать стандартные системные каталоги принадлежащими вашему пакету.

unstripped-binary-or-object

  • Убедитесь, что двоичные файлы являются исполняемыми.

unused-direct-shlib-dependency

Двоичный файл слинкован с библиотекой, но фактически не вызывает ни одну из её функций. Это часто происходит при линковке с библиотекой, которая использует pkgconfig; файл pkgconfig не может знать, какие конкретные функции может потребоваться вызвать вашему двоичному файлу, поэтому он говорит вам линковаться со всеми возможными вариантами.

Одно из исправлений для пакетов, использующих libtool, — поместить это в ваш раздел %build после вызова %configure:

sed -i -e 's! -shared ! -Wl,--as-needed\0!g' libtool

Другое исправление для пакетов, использующих %cmake, — поместить это перед вызовом %cmake:

export CXXFLAGS="%{optflags} -Wl,--as-needed"

wrong-file-end-of-line-encoding

Файл имеет неправильную кодировку конца строки, обычно вызванную созданием или изменением в не-Unix системе. Это может помешать правильному отображению файла в определённых обстоятельствах. UNIX и Linux используют символ перевода строки (Line Feed), а Windows и DOS используют и возврат каретки (Carriage Return), и перевод строки (Line Feed).

  • Удалите символы возврата каретки с помощью perl или sed, использовать dos2unix не обязательно. См. man-страницу SED(1)

perl -i -pe 's/\r\n/\n/gs'
sed -i 's/\r$//'

Want to help? Learn how to contribute to Fedora Docs ›