Fedora-Fr - Communauté francophone Fedora - Linux

Communauté francophone des utilisateurs de la distribution Linux Fedora.

  

Dernière news : Représenter Fedora au Capitole du Libre 2019

#1 01/12/2014 11:59:38

gerald06
Membre
Inscription : 01/12/2014
Messages : 14

Comprendre le principe de mise à jour d'un RPM

Bonjour à tous,

depuis quelques mois, je me suis mis à comprendre et créer des RPMs. Après quelques galères, je commence à bien comprendre ce qu'il faut mettre dans le fichier .spec pour construire mon RPM.
J'y arrive très bien.

Maintenant, je souhaiterai créer des RPM de mise à jour. J'y arrive très bien également mais j'ai quelques soucis pour la gestion des maj. J'aimerai quelques conseils pour adopter la bonne méthode.


Voici un exemple basique sur lequel je travaille.

1- Voici ce que fait mon RPM:
- J'ai un fichier source.tar.gz qui contient des images et des fichiers
- Il contient des fichiers texte que je souhaite mettre dans un répertoire DOCs
- Il contient des images que je souhaite mettre dans un répertoire IMAGES
- Il contient un répertoire /appli2/
Le RPM créé permet à l'installation d'avoir l'arborescence:
/appli1/DOCs
/appli1/IMAGES
Les fichiers étant mis dans les répertoires respectifs


2- Voici ce que fait mon RPM en mise à jour:
- J'ai un fichier .mp3 que je souhaite mettre dans un répertoire MUSIQUES
- Le RPM aura l'arborescence /appli1/MUSIQUES


La mise à jour du second RPM, me permet d'avoir:/appli2/MUSIQUES
mais... /appli1/DOCs et /appli1/IMAGES disparaissent automatiquement


Voici mes questions, pour avoir les 3 répertoires MUSIQUES, IMAGES et DOCs
- Dois-je relivrer dans mon paquet de mise à jour, les fichiers du premier RPM?
- Dois-je prévoir des sauvegardes avant mise à jour?
- Dois-je déplacer les fichiers initial avant de les repositionner au bon endroit?
- Ne faut-il pas que je crée un script qui déplace, sauvegarde  ou  copie les fichiers du premier RPM?


Je vous remercie de l'aide apportée

Cordialement
gerald06

Hors ligne

#2 01/12/2014 12:46:26

madko
Contributeur Fedora et Linuxé depuis 1994
Modérateur
Lieu : Noisy the Great (9³)
Inscription : 22/12/2006
Messages : 7 373
Site Web

Re : Comprendre le principe de mise à jour d'un RPM

Bonjour,

Et faire des rpms différents ce serait pas plus simple? un rpm qui s'occupe de appli1, un autre de appli2 etc. Tu peux en plus faire ça a partir d'un seul srpm. Sinon tu vas vraiment faire des cas complexes à gérer.

Hors ligne

#3 01/12/2014 13:03:44

pingou
Fedora Addict
Lieu : Toulouse
Inscription : 30/03/2006
Messages : 3 843
Site Web

Re : Comprendre le principe de mise à jour d'un RPM

La mise à jour d'un RPM en général c'est juste mettre à jour la version, la release (éventuellement) et la liste de fichiers dans %files si elle a changé.

J'ai l'impression que tu fait un spec différent pour ce que tu appelles un RPM de mise à jour.

Si tu veux rajouter un fichier dans un RPM, tu prend le spec, change la release, ajoute la source, installe le fichier et ajuste %files et voila :)


On a pas inventé l'électricité en cherchant à améliorer la bougie...
-- Si c'est pas sur le bugzilla, c'est pas un bug ! --

Hors ligne

#4 01/12/2014 14:17:15

gerald06
Membre
Inscription : 01/12/2014
Messages : 14

Re : Comprendre le principe de mise à jour d'un RPM

Merci pour vos réponses.

Pour préciser à Madko (que je remercie de sa réponse), mon exemple n'est qu'un cas pour expliquer ma problématique des mises à jour.

Donc, si j'analyse bien vos réponses, le principe d'une mise à jour de RPM s'est de reprendre le .spec de l'ancienne version en y ajoutant les nouveautés et en éventuellement en supprimer.
C'est un peu ce que je pensais mais je n'en étais pas 100% convaincu. Précédemment, je me disais qu'une mise à jour pourrait correspondre à simplement la livraison d'un fichier.

Maintenant, cela m'éclaire bien.

J'ai une question complémentaire concernant les mises à jour.

Conservons l'exemple précédent.

1- je fais l'installation du premier RPM
Les fichiers se déploient où le RPM le leur demande
Dans le répertoire DOCS j'ai un fichier toto.txt, que je vais modifier après installation soit manuellement, soit par script. Bref le fichier est personnalisé.

2- je fais ma mise à jour via le second RPM :
a- Si je reprends la réponse de Pingou, je dois relivrer le fichier toto.txt dans mon RPM de mise à jour. Celui-ci n'écrasera-t-il pas le fichier toto.txt contenant les modifications? et donc ne me retrouverais je pas avec un fichier toto.txt initial? Dois-je faire une sauvegarde au préalable pour qu'en post installation le fichier toto.txt soit recopié?
b- Si je ne relivre pas le fichier toto.txt dans le paquet de mise à jour, je ne vais le mettre dans la partie %file. Ma mise à jour du RPM ne risque-t-elle pas de supprimer automatiquement le fichier toto.txt?


Je site cet exemple, car si j'ai bien compris, dans le cas d'une mise à jour, la procédure d'installation s'effectue en premier.
La procédure de désinstallation de la version précédente s'effectue ensuite., et risque de supprimer des fichiers et/ou répertoire nécessaire

Merci pour vos réponses

Cordialment
Gérald

Hors ligne

#5 01/12/2014 14:22:51

pingou
Fedora Addict
Lieu : Toulouse
Inscription : 30/03/2006
Messages : 3 843
Site Web

Re : Comprendre le principe de mise à jour d'un RPM

Tu peux marquer certain fichier dans ton fichier spec pour qu'il ne soit pas écraser lors de la mise à jour.

Pour cela tu mets devant le fichier dans la section %files
%config(noreplace)

Par exemple:
%config(noreplace)%{_sysconfdir}/gitweb.conf


On a pas inventé l'électricité en cherchant à améliorer la bougie...
-- Si c'est pas sur le bugzilla, c'est pas un bug ! --

Hors ligne

#6 01/12/2014 15:52:42

gerald06
Membre
Inscription : 01/12/2014
Messages : 14

Re : Comprendre le principe de mise à jour d'un RPM

Effectivement, je viens de tester cette commande.

Cela est vraiment très intéressant

J'avance.

Hors ligne

#7 01/12/2014 17:29:10

madko
Contributeur Fedora et Linuxé depuis 1994
Modérateur
Lieu : Noisy the Great (9³)
Inscription : 22/12/2006
Messages : 7 373
Site Web

Re : Comprendre le principe de mise à jour d'un RPM

%config(noreplace) te feras un .rpmnew du fichier du rpm
%config posera le fichier du rpm et te feras une copie du fichier déjà présent en .rpmsave

Tout ça si le fichier cible a été modifié. D'où l'intérêt d'avoir une liste bien propre des fichiers apportés par le RPM (il stock une somme de controle pour savoir si le fichier a été modifié)

Hors ligne

#8 14/12/2016 11:20:58

RPMnoobs
Membre
Inscription : 12/12/2016
Messages : 20

Re : Comprendre le principe de mise à jour d'un RPM

Bonjour,

Je me permets de up cette discussion car j'ai le même problème que Gérald a rencontré en 2014.

Je comprends toutes vos réponses mais mon cas est un peu plus complexe.

L'application que je veux mettre en place et installer via RPM est très lourde.
C'est pour cela que j'aimerai distinguer 2 modes bien différents.

En mode première installation ou changement de version, l'arborescence entière de l'application est livrée.
En mode mise à jour, le nouveau fichier ou encore les fichiers modifiés sont livrés seuls.

Comme vous pouvez le voir cela pose problème lors des mises à jour, car RPM supprime l'ancienne version/release.

Je ne peux pas me permettre de faire différents .rpm (un pour mise à jour, un pour première install,...).
Je ne peux pas non plus utiliser les Deltas RPM car cela nécessiterai plusieurs manipulations côté clients.

Je veux éviter d'utiliser des patchs.

N'y a t-il aucune solution pour livrer LE fichier modifié, supprimé ou ajouté sans devoir livrer le paquet entier et sous les même RPM?

Je vous remercie d'avance pour vos réponses et je m'excuse si ma question est un peu floue..

Cordialement,
Théo

Hors ligne

#9 14/12/2016 11:44:39

remi
Crazy PHP packages monkey... !
Rédacteur Wiki
Lieu : Champagne...
Inscription : 16/10/2004
Messages : 5 569
Site Web

Re : Comprendre le principe de mise à jour d'un RPM

> Je ne peux pas non plus utiliser les Deltas RPM car cela nécessiterai plusieurs manipulations côté clients.

Ben non, c'est automatique (c'est juste le dépôt qui doit fournir les drpm).

> L'application que je veux mettre en place et installer via RPM est très lourde.

Elle doit sans doute pouvoir être décomposée en différents composants, chacun distribué dans son RPM, et chacun ayant son cycle de vie.

Après... très lourde... ça veux dire quoi ? (j'ai du mal à comprendre où est vraiment le problème)

Dernière modification par remi (14/12/2016 11:45:35)

Hors ligne

#10 14/12/2016 11:59:40

RPMnoobs
Membre
Inscription : 12/12/2016
Messages : 20

Re : Comprendre le principe de mise à jour d'un RPM

Merci remi pour ta réponse.

"L'application est très lourde", ce que je veux dire par là, c'est que son arborescence est assez importante.
En fait, pour simplifier le truc, je dois trouver une solution permettant de gérer les mises à jour en ne devant pas envoyer les sources complètes en .rpm à chaque fois.

Je me suis penché sur ces .drpm, à ce que j'ai compris, la seule manière de les installer est yum.
Mais certains clients ne dispose pas de distribution qui intègre yum (comme AIX par exemple), même si une install est toujours possible..

Hors ligne

#11 15/12/2016 12:14:20

madko
Contributeur Fedora et Linuxé depuis 1994
Modérateur
Lieu : Noisy the Great (9³)
Inscription : 22/12/2006
Messages : 7 373
Site Web

Re : Comprendre le principe de mise à jour d'un RPM

Une arborescence assez importante ? Ce n'est toujours pas un soucis, regarde les appli complexes comme postgres, oracle etc elles sont pourtant packagées comme il faut en RPM.

Il faudrait voir version de RPM sur tes AIX car en fonction de celle-ci le payload (la taille max) du rpm peut varier. Depuis un moment on est autour des 5Go. C'est dans ce genre de grandeur que ton appli se situe ?

Ensuite a part faire comme remi l'a suggéré et découper ton appli en composant il n'y aura pas de solution miracle.

Hors ligne

#12 16/01/2017 17:39:27

RPMnoobs
Membre
Inscription : 12/12/2016
Messages : 20

Re : Comprendre le principe de mise à jour d'un RPM

Bonjour,
Je reviens sur cette discussion car je m'étais mal exprimé sur mon besoin, je viens de relire la discussion.
En fait, je ne peux pas relivrer le paquet entier avec les fichiers non modifiés, tout simplement car RPM nettoie/supprime l'ancienne version, et cela dérange les clients.

Le fait d'écraser des fichiers non modifiés dérangent les clients et cela n'est pas possible, car il faudrait arrêter et redémarrer l'application.

Votre première solution a l'air d'être la meilleure : découper le RPM en plusieurs parties, ou bien gérer via les .drpm.
Merci pour vos réponses qui datent de maintenant 1 mois, je ne les avais pas tout à fait assimilé à l'époque. :D

Dernière modification par RPMnoobs (17/01/2017 10:52:36)

Hors ligne

#13 11/09/2019 16:17:16

gerald06
Membre
Inscription : 01/12/2014
Messages : 14

Re : Comprendre le principe de mise à jour d'un RPM

Bonjour,

je reviens sur vos contributions... et oui cela fait longtemps et j'ai perdu un peu le fil.
Pour information, j'avais construit un RPM que j'ai installé dans divers environnements dont un de production.
Cela fonctionne parfaitement.

Entre temps des mises à jour ont été nécessaire afin de modifier des fichiers ou pour en ajouter.
Par contre, jusqu'à présent, ceci a été fait par ANSIBLE...
Donc, on n'est plus avec le contenu du paquet original.

Cela ne me plait pas trop, car si je devais déployer sur un  nouveau serveur, je serais obligé d'installer le RPM puis passer le playbook ANSIBLE (sans en oublier). Bref, cela n'est pas très propre.


Comment pourrais-je procéder?
1- Je me dis que je pourrais RPM"isé" la partie réalisée par ANSIBLE tout en y ajoutant une dépendance au paquet RPM de base.

2- Je me dis que je pourrais faire évoluer le RPM original pour en faire une release supérieure.


Pour la solution 1:
Je la trouve intéressante, mais il faut savoir qu'il y a 2 RPMs à passer pour être en dernière version de l'environnement.

Pour la solution 2:
Je la trouve tout aussi intéressante, mais j'ai peur de flinguer des fichiers de la version 1 qui (par exemple) auraient évolués pour les besoins du cycle de vie de mon application. Exemple, j'ai un fichier "toto" qui contient une liste de prénoms à la base. Entre temps, l'application a vécu. Le fichier "toto" a évolué et contient maintenant des couleurs.
Si je fais un RPM pour une maj, j'ai peur d'avoir un fichier "toto" revenant à l'état initial cad avec uniquement des prénoms.

Que me conseilleriez vous

Merci

Dernière modification par gerald06 (11/09/2019 16:44:46)

Hors ligne

#14 11/09/2019 16:57:45

madko
Contributeur Fedora et Linuxé depuis 1994
Modérateur
Lieu : Noisy the Great (9³)
Inscription : 22/12/2006
Messages : 7 373
Site Web

Re : Comprendre le principe de mise à jour d'un RPM

N'oublie pas que 2 paquets RPMs ne peuvent apporter les mêmes fichiers. Si les évolutions par ansible n'apporte que des nouveaux fichiers tu peux en effet créer un nouveau.

Normalement la solution 2 est la solution la plus propre. Surtout si tu as bien listé dans %files les fichiers de conf (option config avec éventuellement replace ou noreplace), ceux-ci ne seront pas écrasés par les mises à jour du RPM (mais un fichier rpmnew ou rpmsave en fonction du replace/noreplace).

Après si d'autres fichiers sont écrasés, ce sera l'occasion de les tracer et de voir ce qu'il en est. Est-ce une modification normal à backporter dans le RPM, ou autre cas de figure. Donc bien faire un backup avant de tester les mises à jour, et comparer les fichiers avant/après pour voir tout ça. Au pire s'ils ont un ansible, il pourra être rejoué et refaire les modif ecrasées par le RPM ?

Hors ligne

#15 12/09/2019 10:07:07

gerald06
Membre
Inscription : 01/12/2014
Messages : 14

Re : Comprendre le principe de mise à jour d'un RPM

Bonjour,

du coup, je pense partir sur la solution 2.

Par contre, si je décide d'utiliser la valeur %noreplace, je risque d'avoir beaucoup de fichiers .rpmnew présents dans mon environnement suite à une mise à jour?

Autre point, quelle procédure puis-je utiliser pour lister l'ensemble des fichiers dans le RPM que je vais construire?
Aujourd'hui, j'utilise ce paramétrage:

%files
%defattr(-,root,root,-)
%{DIRXX}/*
%{DIRCC}/*

C'est très pratique mais très générique.

Je n'ai pas obligatoirement la bonne méthode de travail... j'avoue

Merci

Hors ligne

#16 12/09/2019 12:01:16

madko
Contributeur Fedora et Linuxé depuis 1994
Modérateur
Lieu : Noisy the Great (9³)
Inscription : 22/12/2006
Messages : 7 373
Site Web

Re : Comprendre le principe de mise à jour d'un RPM

L'ensemble des bonnes pratiques est plutôt bien référencées ici https://docs.fedoraproject.org/en-US/pa … uidelines/

Mais ta section %files me choque pas, on a rarement besoin d'être plus précis. Et lors de la construction du RPM lui listera de manière exhaustive l'ensemble des fichiers qu'il a trouvé lors de sa compilation. Le rpm -qpl ton_fichier.rpm est la résultat exhaustif de ta section %files.

Pour les .rpmnew oui c'est sûr que tu peux en avoir beaucoup. Pour chaque fichier de conf modifié hors du RPM. A l'admin/exploitant de voir ce qu'il en est.

Hors ligne

#17 12/09/2019 14:49:55

gerald06
Membre
Inscription : 01/12/2014
Messages : 14

Re : Comprendre le principe de mise à jour d'un RPM

Bonjour,


pour compléter les propos, voici quelque chose d'assez intéressant, qui illustre vos propositions: https://www.cl.cam.ac.uk/~jw35/docs/rpm_config.html

Cordialement

Hors ligne

Pied de page des forums