rpm : les dépendances n'échouent pas lors de l'installation/mise à jour simultanée de plusieurs paquets

Question

J'ai un problème avec le régime qui me fait m'arracher les cheveux.

Nous avons créé plusieurs paquets pour le déploiement sur des serveurs internes - certains sont des paquets de base (bibliothèques partagées) qui sont utilisés sur des systèmes différents (mais apparentés) et d'autres sont des bibliothèques spécifiques à une application.

Pour simplifier, les paquets et les exigences sont les suivants :

SharedLib-ver.x
ApplicationLib-ver.x  [Requires SharedLib-ver.x]
UserInterface-ver.x   [Requires ApplicationLib-ver.x]

Pour l'installation, le sysadmin a utilisé la commande atomique

rpm -Uvh SharedLib.rpm ApplicationLib.rpm UserInterface.rpm

Cela fonctionne bien tant que tous les paquets s'installent correctement, mais cela ne fonctionne PAS comme prévu si l'un des paquets ne s'installe pas.

Nous avons vérifié, dans des conditions de test, que rpm établit correctement les dépendances et tente d'installer/mettre à niveau les paquets dans l'ordre correct, quel que soit l'ordre dans lequel ils sont inclus dans la commande atomique rpm -Uvh.

Le problème spécifique survient lorsque l'un des paquets échoue dans l'étape %pre (c'est-à-dire que %pre a un statut de sortie non nul).

Si l'installation se fait à l'aide de la commande d'installation/de mise à niveau atomique comme indiqué ci-dessus, elle signale correctement que

error: %pre(SharedLib-ver.x.noarch) scriptlet failed, exit status 1

pero il continue à mettre à niveau/installer les paquets dépendants.

Cependant, si les paquets sont mis à jour/installés de manière séquentielle, c'est-à-dire :

rpm -Uvh SharedLib.rpm; 
rpm -Uvh ApplicationLib.rpm; 
rpm -Uvh UserInterface.rpm;

l'installation de SharedLib échoue avec la même erreur que ci-dessus, puis refuse correctement d'installer les paquets restants car les dépendances n'ont pas été satisfaites. C'est le comportement que j'attendais.

Pour ce que ça vaut, la même chose se produit également si le scriptlet %pretrans se termine avec un état de sortie non nul (par définition, je pensais que le pretrans était censé être terminé avant la transaction rpm commence !). J'ai vu qu'il a été suggéré que la vérification explicite des dépendances et des versions pourrait être incluse dans la section %pretrans, mais cela ne me semble pas correct et semble aller à l'encontre de la raison d'être d'un gestionnaire de paquets !

La version du rpm est 4.8.0 et nous avons vérifié ce comportement sur les serveurs CentOs et RedHat.

Tout d'abord, est-il réellement possible d'installer plusieurs paquets en une seule commande atomique telle que celle présentée, tout en respectant les dépendances fournies par ces paquets ?

Et si oui, comment puis-je y parvenir ?

Je suis sûr que la raison et/ou la solution est triviale, mais je tourne en rond sur ce sujet et je n'arrive pas à trouver une solution.

EDIT

Suite aux commentaires de Matt Schuchard (merci), j'ai essayé l'approche "yum install".

Suppression de la sortie script et autres infos superflues, en cours d'exécution :

yum install ApplicationLib-ver.x.noarch.rpm UserInterface-ver.x.noarch.rpm SharedLib-ver.x.noarch.rpm

donne

Examining UserInterface-ver.x.noarch.rpm: UserInterface-ver.x.noarch
Marking UserInterface-ver.x.noarch.rpm to be installed
Examining SharedLib-ver.x.noarch.rpm: SharedLib-ver.x.noarch
Marking SharedLib-ver.x.noarch.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package UserInterface.noarch 0:ver.x will be installed
---> Package ApplicationLib.noarch 0:ver.x will be installed
---> Package SharedLib.noarch 0:ver.x will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================================================================================================
 Package                                  Arch                    Version                     Repository                                                Size
=============================================================================================================================================================
Installing:
 UserInterface                            noarch                     x                     /UserInterface-ver.x.noarch                                 203 k
 ApplicationLib                           noarch                     x                     /ApplicationLib-ver.x.noarch                                2.0 M
 SharedLib                                noarch                     x                     /SharedLib-ver.x.noarch                                      19 M

Transaction Summary
=============================================================================================================================================================
Install       3 Package(s)

Total size: 21 M
Installed size: 21 M
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction

error: %pretrans(SharedLib-ver.x.noarch) scriptlet failed, exit status 1
Error in PRETRANS scriptlet in rpm package SharedLib-ver.x.noarch

  Verifying  : ApplicationLib-ver.x.noarch                                                                                                   1/3
  Verifying  : UserInterface-ver.x.noarch                                                                                                    2/3
  Verifying  : SharedLib-ver.x.noarch                                                                                                        3/3

Installed:
  UserInterface.noarch 0:ver.x                                        ApplicationLib.noarch 0:ver.x

Failed:
  SharedLib.noarch 0:ver.x

Complete!

Donc yum obtient les dépendances de base et l'ordre d'installation correct (vraisemblablement à partir de rpm de toute façon) mais après avoir fait un 'yum install <packages>', rpm -qa montre ApplicationLib et UserInterface installés, mais SharedLib PAS installé, ce qui est exactement le même problème que j'ai quand j'installe directement avec rpm !

Pour être absolument sûr à 100%, j'ai tout désinstallé et j'ai ensuite essayé (tour à tour) de faire rpm install, rpm upgrade et yum install ApplicationLib-ver.x.noarch et en chaque Dans ce cas, il échoue comme prévu car la SharedLib n'est pas présente.

EDIT (2)

Merci, Jeff, pour votre réponse complémentaire.

J'essaie à 100% d'éviter tout script "fantaisiste" dans les tests %pre - cela donne l'impression d'essayer de forcer un comportement qui (si tout est bien configuré), devrait être géré intrinsèquement par rpm.

Ma première approche a été (exactement comme vous le suggérez) d'ajouter des dépendances étroites (spécifiques à la version).

c'est-à-dire dans ApplicationLib

Requires: SharedLib = %{version}

et dans UserInterface,

Requires: ApplicationLib = %{version}

Lorsque l'expansion de %{version} est la même dans tous les cas

Cela fonctionne parfaitement si les paquets sont installés séquentiellement, mais ce qui me trouble encore, c'est pourquoi rpm/yum ignore la SharedLib, mais continue néanmoins à installer les paquets qui en dépendent si les trois paquets sont installés en une seule commande.

Les choses seront peut-être plus claires si j'explique que ces paquets constituent une application web dorsale et que la mise à jour de certaines parties mais pas d'autres risque, au mieux, de provoquer une expérience utilisateur insatisfaisante et, au pire, une corruption des données. Pour minimiser ce risque, SharedLib effectue un certain nombre de tests de pré-installation pour s'assurer que le système est sûr et prêt à accepter une mise à jour (par exemple, que le serveur web est dans un état sûr pour poursuivre l'installation - présent et arrêté) et un certain nombre d'autres tâches ménagères (par exemple, l'arrêt des services personnalisés qui font également partie de l'application, la rotation des journaux versionnés, etc) s'il est sûr de procéder.

Si le serveur est (par exemple) présent mais qu'il fonctionne et sert des pages, il n'est pas sûr de poursuivre une étape de la mise à niveau. Le rpm sharedLib se termine donc et explique à l'administrateur système ce qui est nécessaire pour poursuivre en toute sécurité. Il est clair que si les bibliothèques dépendantes sont installées indépendamment d'une défaillance de la dépendance de base, il s'agit d'une situation indésirable.

D'accord, il s'agit d'une assurance contre les doigts précipités (les instructions d'installation sont déjà explicites en ce sens que le serveur ne doit pas être en cours d'exécution), mais cela ne semble pas être une chose déraisonnable à faire (YMMV !).

Je peux, bien sûr, demander que les rpms ne soient pas installés dans une commande yum/rpm d'une seule ligne, mais j'ai l'impression que c'est quelque chose que rpm devrait être capable de gérer de manière prévisible, à condition que tout soit correctement configuré. garantie que ces instructions seront de toute façon respectées.

Answer 1

On peut supposer que vous souhaitez un comportement de mise à niveau atomique tout ou rien pour 3 paquets avec rpm et que vous essayez de le faire respecter avec des tests scriptés.

Vous ne réussirez jamais avec scripts en utilisant %pretrans à cause du contexte : rien dans le jeu de transactions actuel n'est installé lorsque %pretrans scripts est exécuté ; par conséquent, vous ne pouvez pas écrire un scripts qui teste la réussite de l'installation.

Vous semblez vous attendre à ce qu'un échec de %pre dans un prérequis entraîne l'échec des paquets dépendants. Ce n'est pas comme cela que %pre fonctionne : un échec de %pre fera sauter ce paquet (avec un avertissement). C'est en fait ce que vous voyez avec rpm/yum, la principale différence étant que yum semble bloquer le message d'avertissement de rpm.

(à part) Vous pouvez probablement ajouter des tests %pre explicites des prérequis pour sauter les installations des paquets dépendants si un prérequis ne s'installe pas, mais ce n'est toujours pas un comportement atomique tout ou rien car rpm n'annulera pas les installations réussies qui ont déjà été effectuées.

En attendant, écrire des tests %pre n'est pas la bonne approche. Vous devez vous concentrer sur les modes d'échec de votre application. Vraisemblablement, vous vous inquiétez des défaillances de l'interface utilisateur lorsque les bibliothèques sont mises à jour sous une application en cours d'exécution. Tout d'abord, les applications en cours d'exécution ont un compte de référence sur les bibliothèques partagées et continueront à fonctionner même si les bibliothèques sont supprimées par les mises à jour de paquets.

Si, par exemple, votre application fait appel à un exécutable qui est d'une manière ou d'une autre incompatible après/pendant une mise à niveau, il faut traiter ce problème dans l'application, et non dans l'emballage.

Sinon, l'ajout de dépendances étroites (c.-à-d. l'utilisation d'une version et d'une publication spécifiques) garantira que tous les paquets, ou aucun, seront inclus dans la transaction de mise à niveau. RPM (à moins de pathologies exceptionnelles comme une coupure de courant et/ou un manque d'espace disque, ou un emballage défectueux, ou un rpm défectueux) réussira à s'installer.

Alors, quel type d'échecs vous inquiète ? Il y a probablement une solution...