Häufige Rpmlint-Fehler

Dies ist eine Sammlung von Informationen zum Umgang mit rpmlint. Beachten Sie, dass Sie als Erstes die Option -e für rpmlint verwenden sollten, um zusätzlichen Erläuterungstext anzuzeigen. Zum Beispiel:

rpmlint -e description-line-too-long

description-line-too-long:
Your description lines must not exceed 80 characters. If a line is exceeding
this number, cut it to fit in two lines.

Die hier bereitgestellten Informationen sind nicht vollständig. Sie decken einige Szenarien ab, für die schnelle Lösungen bekannt sind. Es handelt sich auch nicht um eine Universallösung für jeden Fall, und sie sollte im Kontext der Erstellung Ihres RPM-Pakets sorgfältig geprüft werden. Manche rpmlint-Warnungen sollten für bestimmte Pakete nicht behoben werden; beispielsweise können Warnungen zu nicht standardmäßigen Gruppen oder Benutzern oder zu Setuid-ausführbaren Dateien für manche Pakete durchaus berechtigt sein. Beschreibungen verschiedener rpmlint-Probleme finden Sie in den vom Paket rpmlint installierten Dateien unter /usr/lib/python3.14/site-packages/rpmlint/descriptions/.

Weitere Informationen zum rpmlint-Projekt finden Sie im link:https://github.com/rpm-software-management/rpmlint [Rpmlint GitHub-Projekt].

debuginfo-without-sources

rpmlint -e debuginfo-without-sources liefert einen guten Gesamtüberblick. Siehe auch Compiler Flags. Um das Problem zu beheben, stellen Sie sicher, dass Debug-Symbole erstellt und nicht entfernt werden, damit sie für die Nachbearbeitung von rpmbuild verfügbar sind.

file-not-utf8

Zeigt an, dass die Textkodierung der angegebenen Datei, in der Regel einer Dokumentationsdatei, nicht UTF8 ist.

  • Das Problem lässt sich in der Regel beheben, indem man vor der Installation iconv auf die unkomprimierte Datei anwendet. Siehe die Manpage ICONV(1). Um beispielsweise eine in latin-1 kodierte Datei namens AUTHORS neu zu kodieren, können Sie Folgendes verwenden:

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

Oder sehen Sie sich das Beispiel auf der Seite für Perl-Paketbau-Tipps und die allgemeinen Tricks an.

hardcoded-library-path

  • Verwenden Sie keine fest kodierten Pfade in der Spec-Datei. Verwenden Sie stattdessen Makros.

incorrect-fsf-address

  • In jedem Fall muss das Upstream-Projekt darüber informiert werden. Dies ist die einzige Voraussetzung im Zusammenhang mit diesem Fehler.

Die Lizenzdatei, üblicherweise die Datei COPYING, darf aus rechtlichen Gründen nicht verändert werden. Andere Dateien können verändert werden, sofern dies als angemessen erachtet wird.

incoherent-version-in-changelog

invalid-license

Der Wert des License-Tags wurde nicht erkannt.

invalid-soname

Die Behandlung dieses Fehlers hängt vom Ladepfad von ld.so (dem "Linkerpfad") und davon ab, ob es sich um eine private oder öffentliche Bibliothek handelt.

Der Linkerpfad ist %{_libdir} + ein beliebiger Pfad, der in /etc/ld.so.conf oder in einer Datei in /etc/ld.so.conf.d aufgeführt ist.

Öffentliche Bibliotheken sind Bibliotheken, die von anderen Paketen verwendet werden sollen. Andere Bibliotheken, z.B. Plugins und paketinterne Funktionen, sind privat.

Wir haben vier Fälle:

  • Die Bibliothek ist öffentlich. Informieren Sie die Entwickler über das Problem und schlagen Sie vor, die Versionierung zu ergänzen oder zu korrigieren, gegebenenfalls durch einen Patch. Wenden Sie den Patch erst an, nachdem er in die Entwicklerbibliothek übernommen wurde, um Probleme bei Aktualisierungen zu vermeiden.

  • Die Bibliothek befindet sich außerhalb des Linkerpfads. In diesem Fall kann der Fehler ignoriert werden.

  • Die Bibliothek ist privat, aber befindet sich in einem Verzeichnis, das im Linkerpfad enthalten ist. Verschieben Sie die Bibliothek nach Möglichkeit in ein anderes Verzeichnis außerhalb des Linkerpfads. Dies kann eine Anpassung der Bauskripte erfordern.

  • Die Bibliothek ist privat, befindet sich in einem Verzeichnis, das im Linkerpfad enthalten ist, und kann nicht verschoben werden. Sie muss einen Namen haben, der möglichst nicht mit anderen Bibliotheken kollidiert. Filtern Sie gegebenenfalls die „Provides:“-Liste, um sicherzustellen, dass die private Bibliothek nicht sichtbar ist.

Die übliche Methode zum Verschieben einer privaten Bibliothek besteht darin, ein neues Verzeichnis unter %{_libdir} zu erstellen, z. B. /usr/lib/myapp. Tragen Sie es nicht in die /etc/ld.so.conf-Dateien ein! Verwenden Sie stattdessen einen RPATH, damit die Anwendung die Bibliothek findet.

Siehe auch:

no-binary

Das Paket sollte von der „noarch“-Architektur sein, da es keine Binärdateien enthält.

  • Fügen Sie BuildArch: noarch zur Spec-Datei hinzu.

no-documentation

Zeigt an, dass rpmlint keine mit %doc gekennzeichneten Dateien gefunden hat. Dies ist in einigen Fällen akzeptabel:

  • Das Paket verfügt über keinerlei Dokumentation. Das ist ungewöhnlich und im Allgemeinen keine gute Idee; jedes Paket sollte über eine Dokumentation verfügen und zumindest den Lizenztext enthalten. Einige Pakete bieten jedoch interne Hilfesysteme an.

  • Die gesamte Dokumentation ist in einem Teilpaket namens „-doc“ enthalten. Dies ist ungewöhnlich, da die meisten Pakete Lizenztexte, ein Änderungsprotokoll oder andere Informationen enthalten sollten, die besser im Hauptpaket als in einem Teilpaket „-doc“ aufgehoben sind.

  • Es handelt sich hierbei um ein Teilpaket, dessen zugehörige Dokumentation im Hauptpaket enthalten ist. Dies kommt häufig bei Teilpaketen mit der Endung „-devel“ vor. Sie sollten jedoch unbedingt überprüfen, ob die gesamte Entwicklerdokumentation des Hauptpakets im Teilpaket „-devel“ enthalten ist.

no-soname

Gibt an, dass die angegebene gemeinsam genutzte Bibliothek keinen Soname (Feld DT_SONAME ELF) besitzt. Wenn eine ausführbare Datei mit einem gemeinsam genutzten Objekt verlinkt wird, das ein DT_SONAME-Feld enthält, versucht der dynamische Linker beim Ausführen der ausführbaren Datei, das durch das Feld DT_SONAME angegebene Objekt zu laden, anstatt den dem Linker übergebenen Dateinamen zu verwenden. Siehe Handbuchseite LD(1).

Siehe auch:

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

  • You forgot to unset executable bits on files reported by this error. See also: add shebang.

spurious-executable-perm

Indicates that a file has the executable bit set while it probably should not.

  • Unset the executable bit, for example chmod -x README.md in the %install section of your spec file.

standard-dir-owned-by-package

This package owns a directory that is part of the standard hierarchy, which can lead to default directory permissions or ownerships being changed to something non-standard.

  • You should not make Systems standard directory’s to belong to your package.

unstripped-binary-or-object

  • Make sure binaries are executable.

unused-direct-shlib-dependency

A binary is linked against a library but doesn’t actually call any of the functions in it. This often happens when linking against a library which uses pkgconfig; the pkgconfig file cannot know which specific functions your binary may need to call, so it tells you to link against all of the possibilities.

One fix for packages which use libtool is to put this in your %build section after the %configure call:

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

Another fix for packages which use %cmake is to put this before call %cmake:

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

wrong-file-end-of-line-encoding

The file has incorrect end-of-line encoding, usually caused by creation or modification on a non-Unix system. It could prevent the file from being displayed correctly in certain circumstances. UNIX and Linux use the Line-Feed character , whilst Windows and DOS use both a Carriage Return and Line Feed .

  • Strip the Carriage Returns by using perl or sed, using dos2unix is not necessary. See man page SED(1)

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

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