madko
%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é)
RPMnoobs
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
remi
> 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)
RPMnoobs
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..
madko
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.
RPMnoobs
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. 😃
gerald06
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
madko
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 ?
gerald06
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
madko
L'ensemble des bonnes pratiques est plutôt bien référencées ici
https://docs.fedoraproject.org/en-US/packaging-guidelines/
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.
gerald06
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