Kann man "dieses ODER das" -Paket in einer RPM-Spezifikationsdatei verlangen?

30

Weiß jemand, wie man eine alternative Anforderung oder einen Satz von Anforderungen in einer Spezifikationsdatei im Gegensatz zu einer einzelnen Anforderung spezifiziert (oder ob man sie spezifizieren kann)?

Angenommen, es sind zwei Pakete mit dem passenden Namen foo-barund verfügbar bar-foo. Mein Paket benötigt eines davon, aber nicht beide, und es ist mir egal, welches vorhanden ist. Zur Laufzeit verwende ich das, was verfügbar ist.

So effektiv möchte ich sagen:

Requires: foo-bar OR bar-foo

Soweit ich das beurteilen kann, ist das nicht möglich, aber ich schätze, es gibt Leute hier, die viel mehr über RPM wissen als ich. Vielleicht gibt es einen Weg, dies zu tun.

UPDATE: Ich kontrolliere nur das Paketieren von bar-foo, nicht foo-bar, also funktioniert es nicht , wenn beide ein virtuelles Paket bereitstellen.

UPDATE: Was ich eigentlich brauche, ist selbst ein virtuelles Paket in jedem der Pakete. Say foo-bar provides eagle' andbar-foo bietet beagle and my package works with either (or both); but other packages require eithereagle orbeagle orfoo-bar orbar-foo` und das Zielsystem kann entweder eine oder beide installiert.

Derzeit neige ich dazu, dieses Problem mit einem %preSkript zu lösen , das etwa folgende Aufgaben erfüllt:

rpm -q eagle || rpm -q beagle || echo "need eagle or beagle" && /bin/false

Ich bin mir zwar ziemlich sicher, dass dies funktionieren würde, aber es scheint eine brutale Umgehung des RPM-Abhängigkeits-Trackings zu sein. Zum Beispiel würden Sie mein Paket nie sehen, wenn Sie whatrequires foo-baroder gefragt haben whatrequires beagle.

UPDATE: foo-barZumindest für meine Situation ist der Schmerz, dass die Benutzer an einem Ort installiert werden müssen, an dem er möglicherweise nicht installiert wird, geringer als der Schmerz, das RPM-Abhängigkeitsmanagement zu umgehen. Wenn also nicht jemand eine Möglichkeit findet, "dieses ODER das" (was meiner Meinung nach eine großartige Funktion im RPM-Bereich ist) richtig zu fordern, plane ich, dies nur zu fordern foo-barund dann zur Laufzeit zu bar-foowählen , ob es verfügbar ist sie nach welchen Kriterien ich brauche.

UPDATE: eine andere Idee, die auch RPM betrügen würde, aber die Dinge in den richtigen Zustand bringen könnte. Vielleicht könnte ich in der %postRPM-Datenbank direkt fummeln. So %prekonnte ich von einem Schutz für ungültig installieren, und %postwürde rückwirkend RPM sagen , dass ich erfordern entweder foo-baroder bar-foooder beides, je nachdem , was ist da , wenn ich installieren.

Danke für die Vorschläge!

rpm

— Kevin Frost
quelle

Ich weiß, dass das sehr alt ist; aber gibt es jetzt eine gute lösung dafür? Ich mache eine RPM, die Java-1.6.0-openjdk in erfordert: Zeile; aber mit java7; Ich würde gerne auch java-1.7.0-openjdk unterstützen, konnte aber keinen guten Weg finden, um eines dieser beiden in Requires zu setzen:

— vpram86

Wenn Sie die Verpackung von bar-foo steuern, besteht eine mögliche Lösung darin, es Provides: foo-barso zu erstellen , dass beide Abhängigkeiten erfüllt werden. Überprüfen Sie für neuere RPM-Versionen die Booleschen Abhängigkeiten . Halten Sie sich von Abschnitten fern %preund versuchen Sie nicht, das System zu zerstören . %post

— Forcefsck

13

Dies ist ab RPM 4.13 möglich.

https://rpm.org/user_doc/boolean_dependencies.html

Es kann einfach sein als: Requires: (pkgA >= 3.2 or pkgB)

— Carlwgeorge
quelle

Aus dem Dokument sieht es so aus, als ob diese nicht mit verwendet werden dürfen, nur die 'schwachen' Abhängigkeiten stimmen?

— Dsollen

Der zweite Link zeigt, dass sie mit Requires verwendet werden können. Der erste Link erwähnt, dass die Verwendung auf diese Weise in Fedora nicht zulässig ist, dies jedoch nicht für benutzerdefinierte Pakete gilt.

— Carlwgeorge

9

Diese Art von Verhalten wird bereits von mehreren Paketen ausgeführt, beispielsweise von Mail-Transport-Agents. Mit diesen virtuellen Paketen kann Ihr System feststellen, ob eine von ihm benötigte Funktion bereits von einem anderen Programm bereitgestellt wird.

Sehen Sie, ob das Beispiel für virtuelle Pakete in rpm.org Ihnen hilft.

— Janne Pikkarainen
quelle

Vielen Dank. Ich denke nicht, dass virtuelle Pakete mein spezifisches Problem hier lösen werden, aber ich stimme zu, dass sie sehr nützlich sind. In meinem Fall möchte ich kein gemeinsames Feature von beiden foo-barund benötigen bar-foo, und da ich die Verpackung von nicht kontrolliere, foo-barkann ich sie nicht einfach beide bereitstellen lassen support-for-mypackage. Wenn ich das Packen beider alternativer Voraussetzungen kontrollieren würde, wäre ein gemeinsam genutztes virtuelles Paket in der Tat eine großartige Lösung.

— Kevin Frost

5

Zwei Möglichkeiten:

Wenn das Teil foo-barund bar-fooSie verwenden eine gemeinsame Datei ist , können Sie nur Require /path/to/file(I denke so, meine Prüfung beschränkt war).

Ihre Situation ähnelt optionalen Abhängigkeiten. Die Art und Weise, wie sie behandelt werden, besteht darin, ein X-commonPaket und dann ein X-foo-barPaket zu haben, das es erfordert, foo-barund ein X-bar-fooPaket, das es erfordert bar-foo.

— Mark Wagner
quelle

Leider gibt es keine gemeinsamen Dateien. Das wäre ein cooler Trick, wenn es einen gäbe, der aber auch gefährlich sein könnte: Einige zukünftige Versionen von foo-barkönnten ihre Dateien verschieben (ich kontrolliere nur bar-foohier). Optionale Abhängigkeiten sind interessant, aber nicht ganz das, was ich brauche, da ich entweder foo-bar oder wirklich brauche bar-foo. Das einzige, was optional ist, ist die Auswahl. Danke für die Antwort.

— Kevin Frost

Das hat mein Problem gelöst! Verschiedene GNU / Linux-Varianten bieten verschiedene virtuelle Python3-Pakete: Python3, Python34, Python35 usw. Damit mein einzelnes Paket auf allen funktionieren kann, konnte ich nurRequire: /usr/bin/python3

— bgStack15

0

Funktioniert es für Sie, wenn Ihr Paket bar-foo die virtuelle Paket-foo-Leiste bereitstellt?

Sie können dann einfach Ihr Burp-Baz-Paket von der Foo-Bar abhängig machen.

Wenn sich das oben Genannte als schwierig anfühlt (wahrscheinlich), müssen Sie möglicherweise zwei Versionen Ihres RPM erstellen, eine abhängig von foo-barund eine abhängig von bar-foo.

— MikeyB
quelle

Verlockend, aber gefährlich: Etwas anderes, was wirklich benötigt wird foo-bar, würde dann kaputt gehen, wenn es bar-fooetwas liefern würde, was es wirklich nicht war. Der Knackpunkt ist, dass ich für mein Paket eine der beiden Voraussetzungen brauche, aber nicht beide; Aber für jedes andere Paket ist möglicherweise nur eines erforderlich. Und ich kann nicht einfach beides verlangen, da es echte Fälle gibt, in denen nur das eine oder andere zur Verfügung steht.

— Kevin Frost

-2

Nichtdeterminismus in automatisierten Systemen (das ist entweder das Abhängigkeitsmanagement oder die Maschinen, die RPMs verwenden) ist eine wirklich schlechte Sache. Sie WOLLEN, dass es in dieser oder jener Situation fehlschlägt, da ein Fehlschlagen immer noch nicht so schlimm ist wie ein unerwartetes Ergebnis.

Lassen Sie das von Ihnen kontrollierte Paket% möglicherweise die Haupttoken bereitstellen, die das unveränderliche Paket auch von% bereitstellt und von denen Ihre andere Software% abhängt. dann muss dein paket% das unveränderbare überflüssig machen. Besonders wenn es bereits vorhanden ist, können Sie es gewinnen über die andere Installation.

Packen und ordnungsgemäße Abhängigkeiten und Installationsvorgänge sind eine schwierige Aufgabe. Das Ziel - zuverlässige, wiederholbare und überprüfbare Installationen - ist so wertvoll, dass Sie die Vorteile erkennen, die es mit sich bringt, wenn Sie es richtig machen.

Die Hölle der Abhängigkeit ist selbstverschuldet. Keine Ausnahmen

— user2066657
quelle

Hier ist der Fisch, den ich dir geben werde: Du brauchst nur einen der beiden, weil beide Dateien oder Ressourcen bereitstellen. Hängen Sie also nicht% vom Namen des Pakets ab, sondern nur von der Datei oder Ressource, die Sie bereitstellen. Ja, Sie werden immer noch Nicht-Determinismus umwerben, aber wenn Sie tatsächlich überlegen, direkt mit der rpmdb zu mucken, überlegen Sie bereits fröhlich, welche Risiken die meisten Menschen zu vermeiden gelernt haben. Ich hoffe, Sie können eine Lösung finden, die nicht so technisch verschuldet ist.

— user2066657