Automatisches Filtern von „Provides“ und „Requires“

Es wird dringend empfohlen, diese Filtermakros vor %description, aber nach allen anderen Definitionen aufzurufen. Dadurch bleiben sie in allen Paketen an einem einheitlichen Ort und werden nicht mit anderen Abschnitten verwechselt.

Diese Filter verwenden reguläre Ausdrücke. Die für diese Filter verwendete Variante regulärer Ausdrücke entspricht dem POSIX.2-Standard (siehe die Handbuchseite regex(7)). In dieser Variante müssen die Zeichen`^.[$()|*+?{` mit Rückschrägstrichen maskiert werden. Da rpm Rückschrägstriche beim Parsen von Spec-Dateien interpretiert, müssen Sie für alle Maskierungen einen doppelten Rückschrägstrich verwenden. Ein einzelner Rückschrägstrich (\) wird durch vier Rückschrägstriche dargestellt.

Der Engine für reguläre Ausdrücke wird nur die endgültige Zeichenkette nach der RPM-Makro-Expansion übergeben. Daher können Sie keine nicht maskierten Daten über RPM-Makros verwenden. Wenn Sie beispielsweise eine Liste von Dateien generieren, die in einem Makro abgeglichen werden sollen, und diese Liste libfoo.so enthält, müssen Sie libfoo\\.so verwenden, um „.“ zu maskieren. Beispiel:

Die Makros %__requires_exclude_from und %__provides_exclude_from können in einer Spec-Datei definiert werden, um zu verhindern, dass der Abhängigkeitsgenerator bestimmte Dateien oder Verzeichnisse nach Abhängigkeiten durchsucht. Diese Makros sollten mit einem regulären Ausdruck definiert werden, der alle Verzeichnisse oder Dateien abdeckt. Zum Beispiel:

Beachten Sie, dass dieses Makro das Makro %filter_provides_in aus den alten Filterrichtlinien ersetzt, aber nicht dieselbe Funktion erfüllt. Insbesondere:

Zusätzlich zur Verhinderung des automatischen Abhängigkeitsaufbaus durch Einlesen von Dateien und Verzeichnissen können Sie RPM anweisen, gefundene Abhängigkeiten zu verwerfen, bevor sie in den RPM-Metadaten gespeichert werden. Verwenden Sie dazu __requires_exclude und __provides_exclude. Diese Makros müssen als reguläre Ausdrücke definiert werden. Wenn ein vom automatischen Abhängigkeitsgenerator von RPM erstellter Eintrag mit dem regulären Ausdruck übereinstimmt, wird er aus den „Requires“ bzw. den „Provides“ herausgefiltert. Beispiel:

Diese Makros erfüllen einen ähnlichen Zweck wie das alte Makro %filter_from_provides, sind aber anders implementiert. Insbesondere verwendete jenes Makro sed-Ausdrücke, während dieses einen regulären Ausdruck benötigt.

In manchen Fällen ist das Filtern überflüssiger Provides:-Einträge für alle Pakete, die ähnliche Funktionen bieten, recht allgemein gehalten. Es gibt einfache Makros, welche die Filter für diese Fälle korrekt einrichten, so dass Sie die Filterung mit nur einer Code-Zeile durchführen können. Falls Sie mehr filtern müssen, als das einfache Makro ermöglicht, können Sie weiterhin die oben genannten Makros verwenden.

Auf einem x86_64-System stellt pidgin-libnotify die Bibliothek pidgin-libnotify.so()(64bit) bereit, was nicht korrekt ist, da sich diese Bibliothek nicht in den vom System durchsuchten Bibliothekspfaden befindet. Es handelt sich um ein privates, nicht globales „Provides“, das daher nicht global über RPM zugänglich gemacht werden darf.

Um es herauszufiltern, könnten wir Folgendes verwenden:

Das Filtern privater Bibliotheken ist derzeit nicht trivial. Der Grund dafür ist, dass die Symbole, die aus den privaten Bibliotheken herausgefiltert werden sollen, üblicherweise von den öffentlichen Anwendungen benötigt werden, die das Paket mitliefert. Um die Symbole zu filtern, müssen Sie herausfinden, welche Symbole RPM für die private Bibliothek extrahiert, und diese anschließend sowohl in %__provides_exclude als auch in %__requires_exclude entfernen.

Nehmen wir beispielsweise an, Sie paketieren eine Anwendung namens foo, die die Datei %{_libdir}/foo/libprivate.so erzeugt, welche Sie filtern möchten, sowie die Datei %{_bindir}/foobar, die diese private Bibliothek benötigt. Sie könnten Folgendes tun:

Ein komplexeres Beispiel finden Sie auf der Mailingliste. Die Wartung kann aufwendig sein, wenn die privaten Upstream-Bibliotheken ihre Namen ändern, aber es ist derzeit die einzige Möglichkeit. Möglicherweise gibt es in Zukunft eine bessere Lösung, aber es gibt noch keine konkreten Pläne, wann diese implementiert werden soll.

Um beispielsweise sicherzustellen, dass ein architekturspezifisches perl-*-Paket keine Dinge bereitstellt oder benötigt, was es nicht sollte, könnten wir einen Aufruf wie diesen verwenden:

Gemäß den Richtlinien darf nichts unter %{_docdir} etwas „Requires“ oder „Provides“ erzeugen. Wir können zu diesem Zweck verhindern, dass alles unter %{_docdir} gescannt wird: