openSUSE:Paketbau Prüfungen

Paketbau

Paketbau Richtlinien - Richtlinien zur Bezeichnung von Paketen - Richtlinien für Spezifikationsdateien - Richtlinien für Patches - Sicherheitsrichtlinien - Richtlinien für Paketgruppen - Paketbau Prüfungen - Kategorien für Desktopmenüs - RPM Makros - Init-Skripte - kleine Skript-Schnipsel - Paketbau Perl - Paketbau-Richtlinie für mehrfach benutzte Bibliotheken - Paketabhängigkeiten - Paketbau von Python-Software - Paketbau Richtlinien für mehrere Versionen

Um Qualität und Beständigkeit aufrecht zu erhalten, hilft ein Satz automatischer Überprüfungen, übliche Paketbau-Fehler aufzuspüren oder/und die Paketbau-Politik während des Paketbaus durchzusetzen.

Überblick

Es gibt drei Methoden, automatische Paketbau-Prüfungen aufzurufen:

brp-check-suse

Bau-Root-Politik-Skripte werden durch rpmbuild nach %install aufgerufen, unmittelbar bevor die aktuellen Binär-Pakete erzeugt werden. Sie haben Zugriff auf die Bau-Wurzel der Pakete. Sie sind sehr nützlich, um die Dateien darin zu modifizieren, z. B. um die Anleitungs-Seiten zu komprimieren.

post-build-checks

läuft durch das Bau-Skript als Root. Solche Skripte haben Zugriff auf die Installation in der virtuellen Maschine und auf die Eigenschaften auf das Bau-System. Sie können die Installation oder das Bau-Ergebnis ändern.

rpmlint

läuft durch das Bau-Skript als unprivilegierter Benutzer. Rpmlint prüft ein Paket nach dem anderen. Paketbauer könnten Falschmeldungen über pro-Paket-Konfigurations-Datei (per package config file) unterdrücken. Hier ist das Paket für openSUSE 12.1: rpmlint.

Aufgrund seiner Flexibilität ist rpmlint die bevorzugte Methode, Pakete zu überprüfen. Wenn möglich, sollten neue Prüfungen in rpmlint implementiert und ältere sollten auf rpmlint portiert werden. Der Rest dieses Artikels gilt für rpmlint.

Bau von Paketen ungeachtet der Fehler

Es ist nur möglich, Fehler zu unterdrücken oder zu entschärfen, die von rpmlint ausgelöst werden aber nicht von post-build-checks oder brp-check-suse. Es gibt keine Möglichkeit individuelle Fehler aus diesen Methoden heraus zu filtern. Man benötigt BuildIgnore für diese Pakete, wenn man wirklich diese Prüfungen temporär vermeiden möchte, bis eine geeignete Lösung gefunden ist.

rpmlint kennt drei Arten von Ergebnissen: Information, Warnung und Fehler. Nicht jeder Fehler ist stark genug, um Bau-Fehler zu verursachen. Darum wird ein Schlechtigkeitswertung für einige Fehler festgelegt. Die Wertung akkumuliert zwischen den Paketen währen eines Baulaufs. Nur wenn der Wert eine bestimmte Schwelle überschreitet, schlägt der Bau fehl.

rpmlint hat nicht immer Recht. So könnte es Sinn machen, bestimmte Fehlermeldungen zu unterdrücken oder den Schlechtigkeitswert zu reduzieren. Zu diesem Zweck kann ein Paket eine spezielle config-Datei mit Kommandos enthalten, die die globale Einstellung außer Kraft setzt.

Damit das funktioniert, fügen Sie eine Datei namens %name-rpmlintrc zu Ihren Quellen hinzu und listen diese in der Spezifikations-Datei auf.

Beispiel:

[...]
Source5:  perl-rpmlintrc
[...]

Unterdrückung von Falschmeldungen

Verwenden Sie diese Methode nur für Falschmeldungen (bei Zweifeln konsultieren Sie bitte die Mailingliste). Um Fehler, die gegen die Distributions-Paketbau-Politik verstoßen, zu entschärfen, verwenden Sie die Methode, die im nächsten Abschnitt beschrieben wird.

Das Kommando addFilter kann verwendet werden, um Fehlermeldungen mit einem normalen Ausdruck heraus zu filtern.

addFilter("perl.* devel-file-in-non-devel-package")

Dieser Beispiel-Filter unterdrückt jeden Treffer der Warnung, die mit devel-file-in-non-devel-package bezeichnet ist, wenn der (Unter-)Paketname perl ist. Grundsätzlich sollten Sie die Prüfung so unspeziell wie nötig schreiben. Um nur einen Treffer in einer besonderen Datei zu unterdrücken, sollten Sie so etwas schreiben, wie

addFilter("spurious-executable-perm .*/usr/share/doc/packages/cups/PrintAnalyzer")

Grundsätzlich können Sie jeden gültigen Perl/Python-Ausdruck zum Filtern verwenden. Und er wird direkt zur Textzeile passen, wie sie von rpmlint ausgedruckt wurde.

Die Unterdrückungs-Datei ist nicht Bestandteil des Binär-Pakets. rpmlint manuell über das erhaltene rpm laufen zu lassen, wird wieder eben diese unterdrückte Warnung ausdrucken. Das ist beabsichtigt. Wenn es eine systematische rpmlint-Warnung gibt, die grundsätzlich beseitigt werden sollte, reichen Sie bitte einen Fehlerbericht ein.

Bestimmte Fehler, wie Verstöße gegen die Sicherheits-Politik, dürfen für Paketen in openSUSE Factory nicht heraus gefiltert werden.

Entschärfung fataler Fehler

Einige Prüfungen, wie die der Sicherheit, haben einen so hohen Schlechtheitsgrad, dass ein einziges Vorkommnis bereits den Bau verhindert. Pakete, die nicht für die Einbeziehung in openSUSE vorgesehen sind, könnten solch einen fatalen Fehler in eine Warnung umwandeln. Um das zu machen, verwenden Sie das Kommando 'setBadness'.

Zum Beispiel, um den Bau eines Paketes zu erlauben, der eine unbefugte Datei-Erlaubnis enthält, fügen Sie folgende Zeile hinzu:

setBadness('permissions-unauthorized-file', 0)

rpmlint Überprüfungen in openSUSE

Nachfolgend werden einige Meldungen von rpmlint näher erläutert.

arch-dependent-file-in-usr-share

Dieses Paket installiert eine Binärdatei im ELF-Format unter /usr/share. Dieses Verzeichnis ist reserviert für Dateien, die von der Architektur unabhängig sind. Binärdateien, die nur auf einer bestimmten Architektur anwendbar sind, sollten unter %libexecdir/Paketname installiert werden.

Als eine Ausnahme für spezielle Pakete versuch diese Prüfung eine Warnung zu vermeiden, wenn der Pfad Architektur-spezifisch ist, wie zum Beispiel: /usr/share/tetex/bin/linux/x86/tetex. Die Verwendung dieser Ausnahme wird nicht empfohlen.

wrong-script-interpreter

Dieses Skript verwendet einen falschen Interpreter in seinem Shebang. Der Skript-Interpreter sollte einen kompletten Pfad zu einem gepackten Interpreter haben. Was bedeutet, es sollte zum Beispiel nicht auf das Verzeichnis /usr/local/bin weisen.

arch-independent-package-contains-binary-or-object

Ihr Paket wurde als noarch gekennzeichnet, aber es enthält ein Binärprogramm das Architektur-spezifisch ist.

library-without-ldconfig-postin

Das Paket installiert eine Bibliothek, aber ruft nicht ldconfig in seiner %post -Section auf. Ohne einem aktualisierten ldconfig-Cache, kann die Bibliothek nicht zuverlässig verwendet werden. Das ist ein häufiges Problem während der Installation, da nachfolgende Pakete könnten die Bibliothek in ihrem %post-Skript benötigen.

file-contains-buildroot

Eine Zeichenkette in der Datei stimmt vollständig mit dem Bau von Root überein. Die Paket-Dateien sollten derartige Details über die Paket-Erstellung nicht enthalten.

files-duplicate

Das Paket enthält einige Dateien doppelt. Das vergeudet Installations-Platz und Paket-Größe. Prüfen Sie, ob Sie folgendes Makro verwenden wollen: %fdupes.

summary-not-capitalized

Paket-Zusammenfassungen sollten mit einem großen Buchstaben beginnen, aber nicht mit einem Punkt (.) enden.

executable-docs

Die Dokumentation unter %docdir enthält ausführbare Dateien. Dokumentationen sollten nicht ausführbar sein.

spurious-executable-perm

Dateien, die nicht als ausführbar vorgesehen sind, sollten als solche gekennzeichnet sein. Das kann die Ursache für Falschmeldungen sein. So überprüfen Sie sorgfältig, ob diese richtig oder falsch sind. Unterdrücken Sie diese.

devel-file-in-non-devel-package

Das Paket enthält einen Inhalt, der in einem Unterpaket -devel sein sollte. Der Vorteil der Bereinigung und die Aufteilung Ihrer Pakete in ein -devel-Paket ist zweifach:

1. Es hält die Installationsgröße für Kunden/Nutzer, die Ihre Quellen nicht selbst kompilieren, klein;
2. Es wird Ihnen erlauben, geeignete Abhängigkeiten zum Unterpaket -devel, wenn erforderlich, hinzu zu fügen. Das macht das Leben für Ihren Kunden leichter: Um das -devel-Paket zu installieren, muss er/sie alle Werkzeuge installieren, die gewöhnlich für dieses Paket gefordert sind. Das macht für sie die Fehlersuche wesentlich einfacher.

Es gibt verschiedene Unterprüfungen, die verursachen könnten, dass diese Prüfung ausgelöst werden könnte.

• Eine Header-Datei unter /usr/include. Sie entdeckt Dateien, die mit .h enden und eine Reihe anderer Erweiterungen als Header-Dateien.

• Ein .so Symlink in %libdir, der auf eine versionierte so-Datei weist. Es kann eine Ausnahme geben, dass die Anwendung versucht, die Bibliothek aus irgend einem Grund mit dlopen(3) zu laden. So könnte es berechtigte Gründe geben, die .so-Datei nicht in ein Unterpaket aufzuspalten. Das sollte aber ein seltenes Ereignis sein.

In den meisten Fällen wird der Fehler durch Versionen von Libtool-Modulen ausgelöst. Plugins sollten mit -avoid-version und -module Parametern in LDFLAGS gebaut werden, was das Auslösen dieser Prüfung ebenso verhindert.

Wenn zum Beispiel die einzige Absicht von Ihnen darin besteht, dass die besondere gemeinsame Bibliothek ein Plugin ist, die von einigen anderen Anwendungen geladen wird (ein gutes Anzeichen dafür ist, dass sie nicht direkt in %libdir installiert ist, aber ein Unterverzeichnis davon, und dieses Unterverzeichnis ist nicht im /etc/ld.so.conf Pfad), dann sollten Sie das LDFLAGS validieren, das verwendet wurde, um dieses Modul zu bauen. Und stellen Sie sicher, dass -module und -avoid-version darin enthalten sind. Um die Versionierung anzuwenden, sollte stattdessen das Unterverzeichnis, in dem die Plugins installiert sind, versioniert werden.

wrong-file-end-of-line-encoding

Einige dieser Dateien besitzen eine Zeilenendung im DOS-Stil (CRLF). Unter gewissen Umständen kann dies Unvereinbarkeiten mit Zuschauer-Anwendungen verursachen. Die Prüfung ist sehr niedrig eingestuft, so dass Sie sich nicht darum sorgen müssen. Wenn Sie zweifel haben, sollten Sie versuchen die in Frage kommende Datei nur in den Unix-Stil LF umschlüsseln.

Sie dürfen nicht dos2unix im iso-Modus verwenden, da das nicht nur CRLF in LF ändert, sondern auch die Kodierung von CP437 zu ISO-8859-1 ändert. Verwenden Sie eine der folgenden Anweisungen

• dos2unix -c ascii file
• perl -i -pe 's/\r\n/\n/gs' file
• sed -i 's/\r$//' file
• sed -i 's/\r//' file (das ist ungenau und könnte '\r's killen, denen kein '\n' vorausgeht.)

in der %prep Sektion. (Andere Abschnitte könnten in Ordnung sein, wenn zum Beispiel der Paketbauinhalt nur der ist, der in %install extrahiert ist.)

wrong-script-end-of-line-encoding

E: foo-package wrong-script-end-of-line-encoding /var/www/foo-package/plugins/foo.php

Diese Skript hat eine falsche end-of-line Kodierung, gewöhnlich hervorgerufen durch Erstellung oder Modifizierung auf einem Nicht-Unix-System. Es wird seine Ausführung verhindern. Lösung: Erstellen Sie Dateien nur auf Linux. Erstellen Sie keine Dateien in einer Nicht-Unix-Umgebung, um sie dann zu einem Paket hinzu zu fügen.

hardlink-across-partition

Ihr Paket enthält zwei Dateien, die offensichtlich fest verlinkt (hardlinked) sind und das wahrscheinlich auf unterschiedlichen Partitionen. Die Installation eines solchen RPM wird fehlschlagen, weil RPMs nicht in der Lage sind den Hardlink zu entpacken, wenn die Dateien, die fest verlinkt sind, landen auf zwei unterschiedlichen physikalischen Partitionen. Aus strategischen Gründen sollten Sie nicht über die ersten zwei Pfadebenen verlinken, z. B. zwischen /srv/ftp und /srv/www oder /etc und /usr.

invalid-spec-name

Die Spezifikations-Datei sollte mit %name.spec benannt werden.

no-packager-tag

Die Spezifikations-Datei enthält keine Markierung des "Paketbauers". (Anmerkung: Eine Spezifikations-Datei sollte diese niemals enthalten, weil es die Leute durcheinander bringt, wenn jemand ein Paket umbaut und dann nicht die richtige Person kontaktieren kann, wenn ein Fehler im Paket vorkommt.)

static-library-without-debuginfo

Eine statische Bibliothek, die in Ihrem Paket enthalten ist, enthält keine Information zur Fehlerbehebung. Verwenden Sie die Konfigurations-Option --disable-static oder rm %buildroot/%_libdir/*.a am Ende des %install-Abschnitts, dann und nur dann wenn keine derartige Option zur Verfügung steht.

shlib-legacy-policy-name-error

Ihr Paket folgt nicht der SUSE Bibliothek Paketbau Richtlinie.

ghost-files-without-postin

Diese Dateien sind nicht selbst im RPM-Archiv, werden aber durch das Paket dynamisch erzeugt, während der Installation oder oft später, wenn ein Dämon läuft. Zum Beispiel sind die Dateien Status- oder Log-Dateien. Sie werden mit dem Paket beseitigt, wenn Sie rpm -e eingeben.

no-default-runlevel

Das Init-Skript sollte ein nicht-leeres Kennzeichen "Default-Start" in seinem INIT INFO Abschnitt haben.

init-script-runlevel-4

Das Init-Skript bezieht sich auf Runlevel 4, der ist als Administrator definiert. Kein Skript der Distribution darf es verwenden. Entfernen Sie '4' aus dem 'Standard-Start'.

dbus-policy-missing-allow

Das Paket dbus verwendete in der Vergangenheit eine zu großzügige Konfiguration, was zu Sicherheitsproblemen (CVE-2008-4311) führte. Während der Untersuchung des Problems, wurde herausgefunden, dass viele Pakete dbus-Konfigurations-Dateien enthalten, die nutzlose Einstellungen enthalten, Einstellungen, die andre Service oder Einstellungen schädigen, die nach der dbus-Sicherheits-Aktualisierung abstürzten.

Lösung: Reparieren Sie die dbus-Konfigurations-Datei. In den meisten Fällen kann die Konfiguration auf wenige Zeilen reduziert werden. Lesen Sie auch: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/318783

In diesem Fall benötigt die dbus config normaler Weise eine Zeile von der Form <allow send_destination="org.foo.bar"/> oder ähnlich. Wenn das fehlt, wird der Service nicht funktionieren, da dbus deny als Standard-Regel verwendet.

dbus-policy-deny-without-destination

'deny'-Anweisungen müssen immer eine 'send_destination' spezifizieren, andernfalls könnten Nachrichten zu anderen Services blockiert werden.

Lösung: Fügen Sie eine 'send_destination'-Markierung zu der gelisteten Datei hinzu.

dbus-policy-allow-without-destination

'allow'-Anweisungen müssen immer eine 'send_destination' spezifizieren, andernfalls könnten Nachrichten zu anderen Services unbeabsichtigt erlaubt werden.

Lösung: Fügen Sie eine 'send_destination'-Markierung zu der gelisteten Datei hinzu.

dbus-policy-allow-receive

Die dbus-Datei enthält eine überflüssige "allow receive_..." Anweisung.

Lösung: Löschen Sie diese.

executable-stack

rpmlint Ausgabe: “Das Binärprogramm erklärt den Stack als ausführbar. Ein ausführbarer Stack ist gewöhnlich ein Fehler, da er nur benötigt wird, wenn der Code GCC Trampolines oder ähnliche Konstruktionen enthalten, die den Code am Stack verwenden. Eine gewöhnliche Quelle für unnötig ausführbare Stack-Fälle sind Objekt-Dateien, die von Assambler-Dateien gebaut werden, die keine geeignete .note.GNU-stack Section definieren.”

Lösungen:

• Ein umfassender Artikel über dieses Problem kann unter http://www.gentoo.org/proj/en/hardened/gnu-stack.xml gefunden werden.
• Wahrscheinlich ist die einfachste Lösung -Wl,-z,noexecstack an den Linker zu geben.
• Vergessen Sie nicht die Unterpaketerzeugung debuginfo in Ihrem Build Service Projekt zu aktivieren oder `obs build --debug` aufzurufen.

generic-name-not-in-filelist

rpmlint Ausgabe: “The generic name is not in a filelist of package, add it to list marked as %ghost. Note: this error will be raised, if you use a hash ($) in file name, use rpm macros in spec file instead.”

Übersetzung: "Der Gattungsbegriff ist in keiner Dateiliste des Paketes enthalten. Fügen Sie ihn in die Liste als %ghost markiert ein. Anmerkung: Dieser Fehler taucht auf, wenn Sie ein Raute-Zeichen ($) in der Dateibezeichnung verwenden. Verwenden Sie statt dessen RPM-Makros in Spezifikationsdateien.

Lösung: Siehe den Abschnitt unten.

generic-name-not-marked-as-ghost

rpmlint Ausgabe: “The generic name is not marked as a ghost, which may cause a problems during update. Mark it as a %ghost in %files section.”

Übersetzung: "Der Gattungsbegriff ist nicht als ghost markiert, was Probleme während der Aktualisierung verursachen könnte. Markieren Sie ihn als %ghost im Abschnitt %files .

Lösung: Der Gattungsbegriff (/usr/bin/java für virtuelle Maschinen in Java) sollten in einer Dateiliste als %ghost-Dateien aufgeführt werden, um den Aktualisierungs- oder Ersatzprozess zuverlässig zu machen. Im anderen Fall ist es - unter bestimmten Umständen - möglich, dass RPM den Gattungsbegriff aus dem Dateisystem entfernen wird, was den Link unterbricht.

Warnung: Diese Richtlinie ist nur für Pakete für openSUSE 11.2 und höher anwendbar. Ältere Versionen enthalten eine RPM-Version, die es nicht erlaubt, dass die gleiche ghost-Datei verschiedenen Paketen gehört. Das würde zu einem Konflikt bei der Installation führen.

Beispiel vom zabbix-Paket (Projekt server:monitoring):

%install
...
# Ghost files must exists in a build root
touch %buildroot/%_sbindir/zabbix-server
touch %buildroot/%_sbindir/zabbix-proxy

%post server-mysql
%_sbindir/update-alternatives \
   --install %_sbindir/zabbix-server \
   zabbix-server \
   %_sbindir/zabbix-server-mysql 11

%files server-mysql
%defattr(-,root,root)
%if 0%{?suse_version} >= 1120
%ghost %_sbindir/zabbix-server
%endif
%_sbindir/zabbix-server-mysql

Beachte, dass die ghost-Datei in Buildroot existieren muss!

no-binary

E: foo-package no-binary

Das Paket sollte gemäß der noarch-Architektur sein, da es kein Binärprogramm enthält. Lösung: Fügen Sie "BuildArchitectures: noarch" zur Spezifikations-Datei hinzu, außer es ist ein Python-Paket. In dem Fall sollten Sie diese Warnung ignorieren.

standard-dir-owned-by-package

E: foo-package standard-dir-owned-by-package /usr/share

Dieses Paket besitzt ein Verzeichnis, dass Teil der Standard-Hierarchie ist. Dass kann zu Standard-Verzeichnis-Erlaubnissen oder Eigentumsrechten führen, die zu etwas nicht standardmäßigem geändert wurden. Lösung: Nehmen Sie keine System-Standard-Verzeichnisse in Ihre %files Liste auf.

non-conffile-in-etc

W: foo-package non-conffile-in-etc /etc/xdg/menus/applications-merged/foo-package.menu

Eine nicht ausführbare Datei in Ihrem Paket wurde unter /etc installiert, aber ist keine Konfigurations-Datei. Alle nicht ausführbaren Dateien unter /etc sollten Konfigurations-Datein sein. Markieren Sie die Datei als %config oder %config(noreplace) in der Spezifikations-Datei.

summary-ended-with-dot

W: foo-package summary-ended-with-dot A content management system for foo package.

Zusammenfassung endet mit einem Punkt. Entfernen Sie den Punkt.

script-without-shebang

E: foo-package script-without-shebang /var/www/foo-package/plugins/foo.php

Die ausführbare Text-Datei enthält kein Shebang. Diese kann nicht ordnungsgemäß ausgeführt werden. Oft ist das ein Zeichen unechten ausführbaren Bits für eine nicht-Skript-Datei oder kann ebenso der Fall für das fehlende Shebang sein. Um diesen Fehler zu beheben, müssen Sie herausfinden, welcher Fall zutrifft und entweder entfernen Sie die ausführbaren Bits oder fügen das Shebang hinzu.

version-control-internal-file

E: foo-package version-control-internal-file /var/www/foo-package/CVS/Entries

Sie haben eine oder mehrere Dateien einbezogen, die intern von einem Versions-Kontroll-System im Paket verwendet werden. Verschieben Sie die Datei aus dem Paket und bauen Sie es um.

Lösung: CVS-Verzeichnisse und alles darunter sollten gelöscht werden.

zero-length

E: foo-package zero-length /var/www/foo-package/foo.js

Lösung: Höchstwahrscheinlich nicht mit Absicht installiert. Sollte entfernt werden.

non-standard-group

W: foo-package non-standard-group Networking/Other

Die Gruppe, die Sie in Ihrer Spezifikations-Datei spezifiziert haben, ist ungültig. Wählen Sie eine bekannte Gruppe aus.

strange-permission

W: foo-package strange-permission foo-package.spec 0744

Eine Datei, die Sie aufgelistet haben, um sie in Ihr Paket einzubeziehen, hat merkwürdige Erlaubnisse. Gewöhnlich sollte ein Datei die Erlaubnisse 0644 (rw-r--r--) haben und ein Verzeichnis 0755 (rwxr-xr-x) haben.

hardcoded-library-path

E: foo-package hardcoded-library-path in %{buildroot}/usr/lib/menu/

Eine Bibliothek wurde zu einem der folgenden Pfade /lib, /usr/lib hart kodiert. Es sollte durch so etwas wie /%_lib oder %_libdir ersetzt werden.

suse-filelist-forbidden-noarch

E: suse-filelist-forbidden-noarch /usr/lib64/aspell-0.60/english-huge.multi is not allowed in a noarch package

Der in Frage kommende Pfad ist Architektur spezifisch, während das Paket als Architektur unabhängig markiert ist. Entweder Sie verschieben die Datei an einen Architektur neutralen Ort oder Sie löschen die Kennzeichnung noarch aus dem Paket.

incoherent-init-script-name

W: incoherent-init-script-name haldaemon ('hal', 'hald')

Diese Bezeichnung für das Init-Skript sollte die gleiche wie die Paketbezeichnung in Kleinbuchstaben sein oder eine mit 'd' angehängt, wenn sie einen Prozess mit diesem Namen aufruft.

Lösung: Benennen Sie das Init-Skript, wie von der Prüfung vorgeschlagen, um.

unstripped-binary-or-object

Dieser Fehler sollte eigentlich im Build Service nie auftreten. Das Bau-Skript räumt Binärprogramme gemäß den globalen Projekt-Einstellungen automatisch auf. Übrig gelassene nicht aufgeräumte Binärprogramme könnten darum einen Fehler im automatischen Auslöse-Prozess anzeigen. Bitte reichen Sie einen Fehlerbericht ein. Bitte räumen Sie Binärprogramme nicht manuell auf. Das würde die Erstellung der Information zur Fehlerbereinigung unterbrechen.

binary-or-shlib-calls-gethostbyname

Die Funktionen gethostbyname*() und gethostbyaddr*() sind veraltet. Neben anderen Dingen sind sie nicht IPv6-bereit. Anwendungen sollten stattdessen getaddrinfo(3) und getnameinfo(3) verwenden. Bitte arbeiten Sie mit der Entwicklung mit, um die Anwendung an die moderne Schnittstelle zu portieren. Ulrich Drepper erklärt die Angelegenheiten detaillierter.

file-not-in-%lang

W: file-not-in-%lang /usr/share/sarg/sarg-php/locale/en_EN/LC_MESSAGES/messages.mo

Eine Übersetzungs-Datei gettext (diese enden mit .mo) ist nicht richtig durch eine Sprache gekennzeichnet. Diese Information könnte für die Zukunft nützlich sein, um fähig zu sein, bestimmte Sprachen während der Installation auszulassen. Das %find_lang Makro kann verwendet werden, um Dateien automatisch zu markieren.

untranslated-desktop-file

Dieser Artikel/Abschnitt benötigt Aufmerksamkeit! Mehr Informationen sollten auf der Diskussionsseite des Artikels zu finden sein.

Wir erhalten Übersetzungs-Fehler, die auftreten, weil Dateien vom Typ .desktop nicht für SUSE Übersetzungen gekennzeichnet sind. Um das zu erreichen, müssen Sie %suse_update_desktop_file auf jeder dieser Dateien laufen lassen. Wenn Sie das machen, wird es den openSUSE Übersetzern und dem SUSE Übersetzer-Team ermöglichen, Übersetzungen für Ihre Desktop-Dateien automatisch während Ihres Paket-Baus hinzu zu fügen.

Beachte, dass dies ein KDE3 oder KDE4-Paket ist. Der Fehler wird verursacht durch einen fehlenden Aufruf von %kde_post_install am Ende des Abschnitts %install.

init-script-without-%stop_on_removal-preun

Diese Paket enthält ein /etc/init.d Skript, das keinen Aufruf zu %stop_on_removal im %preun Skript enthält. Siehe: Paketbau-Konventionen

init-script-without-%insserv_cleanup-postun

Das Paket enthält ein /etc/init.d-Skript und ruft nicht %insserv_cleanup im %postun-Skript auf. Siehe: Paketbau-Konventionen

no-prereq-on

Das Paket enthält ein Skript in der Art %pre, %post, %preun oder %postun, das sich auf ein externes Binärprogramm bezieht, das nicht explizit in der entsprechend geforderten Markierung (Requires(pre):, Requires(post):, Requires: oder Requires:, respectively) aufgeführt ist. Es ist notwendig, das zu beheben, so dass die (De)Installation des Paketes in der richtigen Reihenfolge passiert, z. B. dass die Pakete, die für die Ausführung des %post-Skripts erforderlich sind, bereits installiert sind.

non-ghost-in-var-run

/var/run ist in neueren Distributionen als tmpfs eingehängt. Der Inhalt ist flüchtig. Es macht also keinen Sinn Inhalt in dieses Verzeichnis zu packen.

Lösung: Markieren Sie die Datei darin als %ghost in der Spezifikations-Datei und erzeugen Sie diese stattdessen während der Laufzeit. Z. B. indem Sie diese im Init-Skript anfassen. Oder wenn das Paket kein Init-Skript besitzt über /usr/lib/tmpfiles.d.

non-ghost-in-var-lock

/var/lock ist in neueren Distributionen als tmpfs eingehängt. Der Inhalt ist flüchtig. Es macht also keinen Sinn Inhalt in dieses Verzeichnis zu packen. Das Verzeichnis ist für veraltete Geräte-Lock-Dateien (z.B. LCK..ttyS0) vorgesehen, das von lockdev organisiert wird. Verwenden Sie es nicht für andere Zwecke.

subsys-unsupported

/var/lock/subsys wird in openSUSE weder verwendet noch unterstützt. Andere Distributionen verwenden es, um sicher zu stellen, dass ein Init-Skript gelaufen ist. Es gibt in openSUSE kein Äquivalent. In den meisten Fällen kann können Bezüge auf /var/lock/subsys ersatzlos gelöscht werden. In den Fällen, in denen Init-Skripte spezifische Status-Informationen für das Init-Skript speichern muß, verwenden Sie z. B. /var/run/rcNAME. Lesen Sie den vorhergehenden Abschnitt, warum für diesen Zweck /var/lock nicht zu verwenden ist.

non-position-independent-executable

Gemäß der Distributions-Richtlinie müssen einige Binärprogramme, solche wie die wichtigen Netzwerk-Schnittstellen-Programme oder auch setuid-Binärprogramme, als positions-unabhängig ausführbar (PIE) kompiliert werden. PIE ordnet die Startadresse von Programmen regellos an, um es für Angreifer schwieriger zu machen, Programme zur Ausnutzung von Schwachstellen zu erstellen. Fügen Sie -fPIE zu CFLAGS und -pie zu LDFLAGS des spezifizierten Binärprogramms hinzu.

polkit-unauthorized-privilege

Das Paket erlaubt es einem Angreifer bevorzugte Operationen ohne Authentifizierung auszuführen. Das könnte Sicherheitsprobleme verursachen, wenn es nicht sorgfältig ausgeführt wird. Wenn beabsichtigt ist, das Paket für ein SUSE-Produkt zu verwenden, eröffnen Sie bitte einen Fehlerbericht, um eine Überprüfung des Paketes durch das Sicherheits-Team anzufordern.

suse-dbus-unauthorized-service

Das Paket installiert eine Service-Datei des DBUS-Systems. DBUS-Service betreiben gewöhnlich einen Service als Root, zugunsten von Angreifern, was eine Quelle von Sicherheits-Problemen sein könnte. Wenn also das Paket für die Einbeziehung in ein SUSE-Produkt gedacht ist, reichen Sie bitte einen Fehlerbericht ein, um die Durchsicht des Services durch das Sicherheits-Team zu erbitten.

no-changelogname-tag

Das Paket hat kein Änderungsprotokoll. Bitte fügen Sie %changelog als letzte Zeile in die Datei .spec ein und verwenden Sie 'osc vc', um eine Datei .changes zu erstellen.