È possibile richiedere il pacchetto "this OR that" in un file di specifiche RPM?


30

Qualcuno sa come (o se è possibile) specificare un requisito alternativo o un insieme di requisiti in un file di specifiche, anziché un singolo requisito?

Ad esempio, supponiamo che ci siano due pacchetti disponibili, convenientemente denominati foo-bare bar-foo. Il mio pacchetto richiede uno di questi, ma non entrambi, e non mi interessa quale sia presente. In fase di esecuzione utilizzo qualunque sia disponibile.

Così efficacemente vorrei un modo per dire:

Requires: foo-bar OR bar-foo

Per quanto ne so non è possibile, ma immagino che qui ci siano persone che sanno molto di più di RPM di me, quindi forse c'è un modo per farlo.

AGGIORNAMENTO: Controllo solo il packaging di bar-foo, no foo-bar, quindi avere entrambi fornire un pacchetto virtuale non funzionerà.

AGGIORNAMENTO: La cosa di cui ho effettivamente bisogno è di per sé un pacchetto virtuale all'interno di ciascuno dei pacchetti. Di ' foo-bar provides eagle' andbar-foo fornisce beagle and my package works with either (or both); but other packages require eithereagle orbeagle orfoo-bar orbar-foo`, e il sistema di destinazione può avere uno o entrambi installati.

Al momento sono propenso a risolvere questo problema con uno %prescript che fa qualcosa del tipo:

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

Mentre sono abbastanza sicuro che funzionerebbe, sembra una brutale elusione del monitoraggio delle dipendenze di RPM. Ad esempio non vedresti mai il mio pacco quando glielo chiedi whatrequires foo-baro whatrequires beagle.

AGGIORNAMENTO: Ripensandoci, il dolore di richiedere alle persone di installare foo-bardove potrebbero non essere è meno del dolore di eludere la gestione delle dipendenze RPM, almeno per la mia situazione. Quindi, a meno che qualcuno non trovi un modo per richiedere correttamente "questo OR quello" (che penso sarebbe una grande caratteristica da avere in RPM in generale), allora ho intenzione di richiedere solo foo-bar e quindi, in fase di esecuzione, se bar-fooè disponibile sceglierò tra secondo i criteri di cui ho bisogno.

AGGIORNAMENTO: un'altra idea, che sarebbe anche barare RPM ma potrebbe riportare le cose nello stato giusto. Forse potrei, direttamente %post, giocherellare con il database di RPM. Così %premi potrebbe proteggere da un invalido di installazione, e %postavrebbe effetto retroattivo dire RPM che richiedo uno foo-baro bar-fooo entrambi, a seconda di ciò che è lì quando installo.

Grazie per i suggerimenti!


So che è molto vecchio; ma c'è una buona soluzione ora per questo? Sto realizzando un RPM con java-1.6.0-openjdk in Richiede: linea; ma con java7; Vorrei supportare anche java-1.7.0-openjdk ma non sono riuscito a trovare un buon modo per inserire uno di questi due in Richiede:
vpram86

Se controlli il packaging di bar-foo, una possibile soluzione è costruirla con Provides: foo-bar, quindi soddisfa entrambe le dipendenze. Per le versioni rpm più recenti, selezionare Dipendenze booleane . Stare lontano da %pree %postsezioni, non tentare di sconfiggere il sistema .
forcefsck

Risposte:


13

Questo è ora possibile a partire da RPM 4.13.

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

Può essere semplice come: Requires: (pkgA >= 3.2 or pkgB)


dal documento sembra che questi non possano essere utilizzati con richiede, solo le dipendenze "deboli" sono corrette?
dsollen,

Il secondo collegamento mostra che possono essere utilizzati con i requisiti. Il primo link menziona che usarlo in quel modo non è permesso in Fedora, ma ciò non si applica ai pacchetti personalizzati.
Carlwgeorge,

9

Questo tipo di comportamento è già svolto da numerosi pacchetti, ad esempio agenti di trasporto posta. Quei pacchetti virtuali forniscono al tuo sistema un modo per sapere se una funzionalità di cui hanno bisogno è già fornita da qualche altro programma.

Vedi se l' esempio di pacchetti virtuali in rpm.org ti aiuta.


Grazie. Non penso che i pacchetti virtuali risolveranno il mio problema specifico qui, ma sono d'accordo che sono molto utili. Nel mio caso, non voglio richiedere alcune funzionalità comuni fornite da entrambi foo-bare bar-foo, e poiché non controllo il pacchetto di, foo-barnon posso semplicemente fornire entrambi support-for-mypackage. Se controllassi il pacchetto di entrambi i prerequisiti alternativi, in effetti un pacchetto virtuale condiviso sarebbe un'ottima soluzione.
Kevin Frost,

5

Due possibilità:

Se la parte di foo-bare bar-fooche usi è un file comune puoi semplicemente Require /path/to/file( penso di sì; i miei test erano limitati).

La tua situazione è simile alle dipendenze opzionali. Il modo in cui vengono gestiti consiste nell'avere un X-commonpacchetto e quindi un X-foo-barpacchetto che richiede foo-bare un X-bar-foopacchetto che richiede bar-foo.


Purtroppo non ci sono file comuni. Sarebbe un bel trucco se ci fosse, anche se potenzialmente pericoloso: alcune versioni future di foo-barpotrebbero spostare i suoi file (controllo solo bar-fooqui). Dipendenze opzionali sono interessanti ma non del tutto quello che ho bisogno, dal momento che ho davvero bisogno sia foo-bar o bar-foo ; l'unica cosa facoltativa è la scelta di quale. Grazie per la risposta.
Kevin Frost,

Questo ha risolto il mio problema! Diverse versioni GNU / Linux offrono diversi pacchetti virtuali python3: python3, python34, python35, ecc. Per far funzionare il mio pacchetto singolo su tutti, sono stato in grado di usare soloRequire: /usr/bin/python3
bgStack15

0

Funzionerà per te avere il tuo pacchetto bar-foo fornire il pacchetto virtuale foo-bar?

Puoi quindi fare in modo che il tuo pacchetto burp-baz richieda foo-bar.


Se fare quanto sopra ti fa sentire schizzinoso (probabilmente lo è) potresti dover creare due versioni del tuo RPM, una a seconda foo-bare l'altra a seconda bar-foo.


Allettante, ma pericoloso: qualcos'altro, che ha davvero bisogno foo-bar, si spezzerebbe se pensasse che bar-foostesse fornendo qualcosa che in realtà non era. Il punto critico è che per il mio pacchetto ho bisogno di uno dei prerequisiti ma non di entrambi; ma qualsiasi altro pacchetto potrebbe davvero aver bisogno di uno solo di essi. E non posso nemmeno richiedere entrambi, dal momento che ci sono casi reali in cui sarà disponibile solo l'uno o l'altro.
Kevin Frost,

-2

Il non determinismo nei sistemi automatizzati (che è la gestione delle dipendenze o le macchine che usano gli RPM) è davvero una brutta cosa. VUOI fallire in una situazione come questa o quella, poiché il fallimento non è ancora così grave come un risultato inaspettato.

Per risolvere il problema, forse il pacchetto che controlli% fornisce i token principali che il pacchetto immutabile capita anche di fornire% e da cui dipende l'altro altro software%; quindi fai in modo che il tuo pacchetto% oscilli quello immutabile. Soprattutto se è già in atto, potresti vincerlo sull'altra installazione.

Il confezionamento e la corretta dipendenza e le operazioni di installazione sono un lavoro complicato. L'obiettivo - installazioni affidabili, ripetibili e verificabili - è così prezioso che puoi realizzare i vantaggi di farlo correttamente.

L'inferno delle dipendenze è autoinflitto. Nessuna eccezione


Ecco il pesce che ti darò: è necessario solo uno dei due perché entrambi forniscono alcuni file o risorse. Quindi, non dipendere% dal nome del pacchetto, solo dal file o dalla risorsa che forniscono. Sì, continuerai a corteggiare il non determinismo, ma se in realtà stai prendendo in considerazione l'idea di confondere direttamente con l'rpmdb, stai già prendendo in giro allegramente i rischi che la maggior parte delle persone ha imparato a evitare. Spero che tu possa trovare una soluzione che non incorra in un tale debito tecnico.
user2066657,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.