Peut-on exiger «ce OU cela» dans un fichier de spécifications RPM?

Quelqu'un sait-il comment (ou si l'on peut) spécifier une autre exigence ou un ensemble d'exigences dans un fichier de spécifications, par opposition à une seule exigence?

Par exemple, supposons qu'il existe deux packages disponibles, nommés foo-baret bar-foo. Mon colis nécessite l'un d'eux, mais pas les deux, et je me fiche de savoir lequel est présent. Au moment de l'exécution, j'utilise celui qui est disponible.

Donc, effectivement, je voudrais une façon de dire:

Requires: foo-bar OR bar-foo

Pour autant que je sache, ce n'est pas possible, mais je pense qu'il y a des gens ici qui en savent beaucoup plus sur RPM que moi, alors peut-être qu'il y a un moyen de le faire.

MISE À JOUR: Je contrôle uniquement l'empaquetage de bar-foo, non foo-bar, donc les deux fournissent un paquet virtuel ne fonctionnera pas.

MISE À JOUR: La chose dont j'ai réellement besoin est en soi un paquet virtuel à l'intérieur de chacun des paquets. Supposons que foo-bar provides eagle' andbar-foo fournit beagle and my package works with either (or both); but other packages require eithereagle orbeagle orfoo-bar orbar-foo`, et le système cible peut avoir l'un ou les deux installés.

Je suis actuellement en train de résoudre ce problème avec un %prescript qui fait quelque chose comme:

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

Bien que je sois presque sûr que cela fonctionnerait, cela semble être un contournement brutal du suivi des dépendances de RPM. Par exemple, vous ne verriez jamais mon colis lorsque vous avez demandé whatrequires foo-barou whatrequires beagle.

MISE À JOUR: À la réflexion, la douleur d'exiger que les gens installent foo-barlà où ils pourraient ne pas être moins que la douleur de contourner la gestion des dépendances RPM, au moins pour ma situation. Donc, à moins que quelqu'un ne trouve un moyen d'exiger correctement "ceci OU cela" (ce qui, à mon avis, serait une excellente fonctionnalité dans RPM en général), je prévois d'exiger uniquement foo-bar , puis, au moment de l'exécution, s'il bar-fooest disponible, je choisirai entre les selon tous les critères dont j'ai besoin.

MISE À JOUR: une autre idée, qui tricherait également RPM mais pourrait mettre les choses dans le bon état. Je pourrais peut-être, %postdirectement, jouer avec la base de données de RPM. Ainsi %prepourrait me protéger contre une défaillance de l' installation, et %postserait rétroactivement dire RPM que je requiers soit foo-barou bar-fooou les deux, selon ce qui est là quand j'installation.

Merci pour les suggestions!

Cela est désormais possible à partir du RPM 4.13.

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

Cela peut être simple: Requires: (pkgA >= 3.2 or pkgB)

Ce type de comportement est déjà effectué par plusieurs packages, par exemple les agents de transport de courrier. Ces packages virtuels fournissent à votre système un moyen de savoir si une capacité dont il a besoin est déjà fournie par un autre programme.

Voyez si l' exemple de packages virtuels dans rpm.org vous aide.

Deux possibilités:

Si la partie de foo-baret que bar-foovous utilisez est un fichier commun, vous pouvez simplement Require /path/to/file(je pense que oui; mes tests étaient limités).

Votre situation est similaire aux dépendances facultatives. La façon dont ils sont gérés consiste à avoir un X-commonpackage, puis un X-foo-barpackage qui requiert foo-baret un X-bar-foopackage qui nécessite bar-foo.

Est-ce que cela fonctionnera pour que votre paquet bar-foo fournisse le paquet virtuel foo-bar?

Vous pouvez alors simplement faire en sorte que votre paquet burp-baz nécessite foo-bar.

Le non-déterminisme dans les systèmes automatisés (c'est-à-dire la gestion des dépendances ou les machines qui utilisent les RPM) est une très mauvaise chose. Vous VOULEZ qu'il échoue dans telle ou telle situation, car l'échec n'est toujours pas aussi mauvais qu'un résultat inattendu.

Pour résoudre le problème, peut-être que le package que vous contrôlez% fournit les principaux jetons que le package immuable fournit également% et dont dépendent vos autres logiciels%; alors votre package% obsolète l'immuable. Surtout s'il est déjà en place, vous pouvez le faire gagner sur l'autre installation.

L'empaquetage et les opérations de dépendance et d'installation appropriées sont des tâches délicates. L'objectif - des installations fiables, reproductibles et vérifiables - est si précieux que vous pouvez réaliser les avantages de bien faire les choses.

L'enfer de la dépendance est auto-infligé. Aucune exception