Frage Kann man das "this OR that" -Paket in einer RPM-Spezifikationsdatei benötigen?


Kann jemand eine alternative Anforderung oder einen Satz von Anforderungen in einer Spezifikationsdatei spezifizieren (oder kann man dies), im Gegensatz zu einer einzigen Anforderung?

Angenommen, es sind zwei Pakete verfügbar, die bequem benannt werden können foo-bar und bar-foo. Mein Paket benötigt eines, aber nicht beides, und es ist mir egal, welches Paket vorhanden ist. Zur Laufzeit verwende ich, was immer verfügbar ist.

So würde ich gerne einen Weg finden zu sagen:

Requires: foo-bar OR bar-foo

Soweit ich das beurteilen kann, ist das nicht möglich, aber ich denke, dass es hier Leute gibt, die viel mehr über RPM wissen als ich, also gibt es vielleicht einen Weg, dies zu tun.

UPDATE: Ich kontrolliere nur die Verpackung von bar-foonicht foo-bar, so dass beide ein virtuelles Paket zur Verfügung stellen, wird nicht funktionieren.

UPDATE: Das, was ich eigentlich brauche, ist selbst ein virtuelles Paket in jedem der Pakete. Sagen foo-bar provides eagle' andBar-Foo bietet Beagleand my package works with either (or both); but other packages require eitherAdlerorBeagleorFoo-Barorbar-foo`, und das Zielsystem kann eines oder beide installiert haben.

Ich bin gerade dabei, dies mit einem zu lösen %pre Skript, das so etwas wie

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

Während ich mir ziemlich sicher bin, dass das funktionieren würde, scheint es eine brutale Umgehung der Abhängigkeitsverfolgung von RPM zu sein. Zum Beispiel würden Sie nie mein Paket sehen, wenn Sie gefragt werden whatrequires foo-bar oder whatrequires beagle.

UPDATE: Auf den zweiten Gedanken hin, der Schmerz von Menschen zu installieren foo-bar wo sie vielleicht nicht sind, ist weniger als der Schmerz, das RPM-Abhängigkeitsmanagement zu umgehen, zumindest für meine Situation. Also, es sei denn, jemand findet einen Weg, um "dieses ODER das" richtig zu verlangen (was ich denke, wäre ein großartiges Feature, um im RPM im Allgemeinen zu haben), dann plane ich zu erfordern nur  foo-bar und dann, zur Laufzeit, wenn bar-foo verfügbar ist, werde ich zwischen ihnen nach beliebigen Kriterien wählen, die 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 %postGeige direkt mit der RPM-Datenbank. Somit %pre könnte mich vor einer ungültigen Installation schützen, und %post würde RPM rückwirkend mitteilen, dass ich beides benötige foo-bar oder bar-foo oder beides, abhängig davon, was bei der Installation vorhanden ist.

Danke für die Vorschläge!


26
2017-08-09 11:42


Ursprung


Ich weiß, das ist sehr alt; Aber gibt es dafür jetzt eine gute Lösung? Ich mache ein RPM mit Java-1.6.0-openjdk in Requires: line; aber mit java7; Ich würde gerne auch java-1.7.0-openjdk unterstützen, aber ich konnte keinen guten Weg finden, eines der beiden zu setzen. - vpram86
Wenn Sie die Verpackung von Bar-Foo kontrollieren, ist eine mögliche Lösung, es mit zu bauen Provides: foo-bar, so erfüllt es beide Abhängigkeiten. Überprüfen Sie bei neueren rpm-Versionen Boolesche Abhängigkeiten. Bleiben Sie weg von %pre und %post Abschnitte, Versuchen Sie nicht, das System zu besiegen. - forcefsck


Antworten:


Dies ist ab RPM 4.13 möglich.

https://fedoraproject.org/wiki/Packaging:Guidelines#Rich.2FBoolean_dependencies

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


10
2018-03-03 03:07



aus dem dokument sieht es so aus als könnten diese nicht verwendet werden, nur die 'schwachen' abhängigkeiten sind korrekt? - dsollen
Der zweite Link zeigt, dass sie mit Requires verwendet werden können. Der erste Link erwähnt, dass die Verwendung in Fedora nicht erlaubt ist, aber nicht für benutzerdefinierte Pakete. - carlwgeorge


Diese Art von Verhalten wird bereits von mehreren Paketen, z. B. Mail-Transport-Agents, durchgeführt. Jene virtuelle Pakete Stellen Sie Ihrem System eine Möglichkeit zur Verfügung, um zu wissen, ob eine benötigte Funktionalität bereits von einem anderen Programm bereitgestellt wird.

Sehen ob virtuelle Pakete Beispiel in rpm.org hilft Ihnen.


9
2017-08-09 11:53



Vielen Dank. Ich glaube nicht, dass virtuelle Pakete mein spezifisches Problem lösen werden, aber ich stimme zu, dass sie sehr nützlich sind. In meinem Fall möchte ich keine gemeinsame Funktion von beiden verlangen foo-bar und bar-foo, und da ich die Verpackung von nicht kontrolliere foo-bar Ich kann sie nicht einfach beide zur Verfügung stellen support-for-mypackage. Wenn ich die Verpackung beider alternativer Voraussetzungen kontrollieren würde, wäre in der Tat ein gemeinsames virtuelles Paket eine großartige Lösung. - Kevin Frost


Zwei Möglichkeiten:

Wenn der Teil von foo-bar und bar-foo Sie verwenden eine gemeinsame Datei, die Sie einfach verwenden können Require /path/to/file (ICH denken so; meine Tests waren begrenzt).

Ihre Situation ähnelt optionalen Abhängigkeiten. Die Art, wie sie gehandhabt werden, ist ein X-commonPaket und dann a X-foo-bar Paket, das erfordert foo-bar und ein X-bar-foo Paket, das erfordert bar-foo.


5
2017-08-09 20:25



Es gibt leider keine gemeinsamen Dateien. Das wäre ein cooler Trick, wenn es auch, wenn auch potentiell, gefährlich wäre: eine zukünftige Version von foo-bar könnte seine Dateien verschieben (ich kontrolliere nur bar-foo Hier). Optionale Abhängigkeiten sind interessant, aber nicht ganz das, was ich brauche, da ich wirklich brauche entweder  foo-bar  oder  bar-foo; das einzige, was optional ist, ist die Wahl dessen. Danke für Ihre 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 an allen funktioniert, konnte ich es einfach verwenden Require: /usr/bin/python3 - bgStack15


Wird es für Sie funktionieren, dass Ihr Paket bar-foo das virtuelle Paket foo-bar bereitstellt?

Sie können dann nur Ihr bump-baz-Paket benötigen, foo-bar.


Wenn das obige Gefühl skeezy (es ist wahrscheinlich) ist, müssen Sie möglicherweise zwei Versionen Ihres RPM erstellen, je nachdem foo-bar und die andere abhängig von bar-foo.


0
2017-08-09 13:44



Verlockend, aber gefährlich: etwas anderes, was wirklich nötig ist foo-bar, würde dann brechen, wenn es dachte bar-foo lieferte etwas, was es wirklich nicht war. Der Knackpunkt ist der für meine Paket brauche ich entweder von den Voraussetzungen, aber nicht von beiden; aber jedes andere Paket braucht wirklich nur einen von ihnen. Und ich kann nicht beides auch nur verlangen, da es reale Fälle gibt, in denen nur der eine oder andere verfügbar sein wird. - Kevin Frost


Nicht-Determinismus in automatisierten Systemen (das ist entweder Abhängigkeitsverwaltung oder die Maschinen, die RPMs verwenden) ist eine wirklich schlechte Sache. Sie MÖCHTEN es in einer Dies-oder-Nicht-Situation versagen, da das Scheitern immer noch nicht so schlimm ist wie ein unerwartetes Ergebnis.

Um das Problem zu lösen, haben Sie vielleicht das Paket, das Sie kontrollieren% die Haupttokens zur Verfügung stellen, die das unveränderliche Paket auch% liefert und von dem Ihre andere Software abhängt; dann haben Sie Ihr Paket% obsoletes das unveränderliche. Vor allem, wenn es bereits vorhanden ist, können Sie es über die andere Installation gewinnen.

Das Packen und die richtigen Abhängigkeiten und Installationsvorgänge sind knifflige Arbeit. Das Ziel - zuverlässige, wiederholbare und überprüfbare Installationen - ist so wertvoll, dass Sie die Vorteile erkennen können, es richtig zu machen.

Abhängigkeitshölle ist selbstverschuldet. Keine Ausnahmen


-1
2018-05-10 21:46



Hier ist der Fisch, den ich dir geben werde: Du brauchst nur einen der beiden, weil beide eine Datei oder Ressource zur Verfügung stellen. Also, nicht% hängt vom Namen des Pakets ab, nur von der Datei oder Ressource, die sie bereitstellen. Ja, Sie werden immer noch auf Nicht-Determinismus setzen, aber wenn Sie darüber nachdenken, direkt mit der rpmdb zu meckern, denken Sie schon fröhlich über Risiken nach, die die meisten Menschen vermieden haben. Ich hoffe, Sie können eine Lösung finden, die keine technischen Schulden verursacht. - user2066657