Beryl::Apply::PkgUpgrade
Inherits Beryl::Apply::Primitive < Reference < Object
Primitive pkg-upgrade : met à jour une liste FERMÉE de paquets
(seulement ceux qui sont installés) puis relance les services qui en
dépendent. Conçue pour les paquets maison publiés par poudriere
(ex. une application et ses scripts rc.d qui migrent au démarrage) :
beryl est le seul à mettre à jour ces paquets sur les serveurs.
- pkg-upgrade:
packages: [myapp, myapp-worker] # obligatoire, non vide
restart: [myapp] # optionnel
Lecture de l'état (idempotence) :
. pkg update -q rafraîchit le catalogue (sinon « à jour » ne veut rien
dire) ; fait aussi en dry-run : ne touche que le cache du catalogue,
jamais les paquets installés.
. pkg info -e <p> : un paquet listé mais NON installé est ignoré
(rapporté) — un serveur peut n'avoir que monappli.
. pkg version -URv -l '<' : les paquets installés plus anciens que le
catalogue distant, avec la version disponible (« needs updating (remote
has X) »). Choisi plutôt que d'analyser pkg upgrade -n : c'est la
comparaison de versions de pkg lui-même (epoch, _n, ,n), sortie
ligne à ligne stable, VIDE quand tout est à jour — alors que
pkg upgrade -n mêle dépendances, résumé et formulations variables
(« Your packages are up to date. ») et sort en 1 dès qu'il y a quelque
chose à faire.
Rien à mettre à jour → Skipped. Sinon, en dry-run : plan (paquets
de → vers, services qui seraient relancés). En --apply :
pkg upgrade -r <dépôt> -y <paquets en retard>, un par dépôt d'origine
(%R) des paquets (pkg peut entraîner des dépendances : c'est normal),
puis service <svc> restart pour chaque
service de restart ACTIVÉ (sysrc -n <svc>_enable = YES, casse
ignorée) ; un service non activé est sauté et rapporté. Échec du
pkg upgrade ou d'un redémarrage → Failed (les autres services sont
tout de même tentés, pour ne pas laisser la moitié du parc arrêtée).
Pourquoi -r : un paquet offert par deux dépôts (gmp, mpfr… republiés
par poudriere dans le dépôt maison, copies de FreeBSD-ports) échappe
sinon à la règle « ne pas installer ce qui n'est pas installé » du
solveur de pkg (posée seulement quand il n'en existe qu'UNE variante,
libpkg/pkg_solve.c) : pkg l'installait sans que rien ne le réclame
(loulou, quantas, 27 oct. 2026 ; même remède que beryl upgrade). Un
paquet absent de son dépôt d'origine mais disponible ailleurs : sans
-r.
Class methods
Analyse la sortie de pkg version -URv -l '<' et ne garde que les
paquets de wanted. Une ligne vaut
monappli-1.2.3 < needs updating (remote has 1.2.4).
Le nom se déduit en retirant le dernier -<version> (une version pkg
ne contient pas de tiret ; un nom, si : monappli-devel). Pur.
Groupes {dépôt, paquets} pour pkg upgrade : dépôt d'origine de
chaque paquet (pkg query '%n %R') s'il l'offre encore (pkg rquery -a '%n %R'), sinon nil (pkg upgrade sans -r). Ordre de names. Pur.
Instance methods
params est le hash brut du step YAML (ex: {"packages" => [...]}),
déjà interpolé par l'Executor. context porte les infos
dérivées du host (cf. Context).
Nom kebab-case utilisé comme clé de step dans les recettes (« pkg-install », « service-enable », …).