dpkg-maintscript-helper - En ligne dans le Cloud

PROGRAMME:

Nom

dpkg-maintscript-helper - contourne les limitations connues de dpkg dans les scripts du responsable

SYNOPSIS

dpkg-maintscript-helper commander [paramètre...] -- paramètre-script-maint...

COMMANDES ET PARAMETRES

supports commander

rm_conffile fichier de configuration [version-antérieure [paquet]]

mv_conffile ancien-conffile nouveau-conffile [version-antérieure [paquet]]

lien symbolique_to_dir chemin d'accès ancienne cible [version-antérieure [paquet]]

dir_to_symlink chemin d'accès nouvelle-cible [version-antérieure [paquet]]

DESCRIPTION

Ce programme est conçu pour être exécuté dans des scripts de mainteneur afin d'accomplir certaines tâches qui
dpkg ne peut pas (encore) gérer nativement, soit en raison de décisions de conception, soit en raison de
limites.

Beaucoup de ces tâches nécessitent des actions coordonnées de plusieurs scripts de mainteneur (préinst,
post-installation, prématuré, après-midi). Pour éviter les erreurs, le même appel doit simplement être mis dans tous
scripts et le programme adaptera automatiquement son comportement en fonction de l'environnement
variable DPKG_MAINTSCRIPT_NAME et sur les arguments des scripts du responsable que vous devez
avant après un double tiret.

COMMUNE PARAMETRES

version-antérieure
Définit la dernière version du package dont la mise à niveau doit déclencher le
opération. Il est important de calculer version-antérieure correctement afin que le
les opérations sont correctement effectuées même si l'utilisateur a reconstruit le package avec un
version locale. Si version-antérieure est vide ou omis, l'opération est tentée
chaque mise à jour (remarque : il est plus sûr de donner la version et de faire essayer l'opération
juste une fois).

Si le fichier de configuration n'a pas été livré depuis plusieurs versions et que vous êtes maintenant
modifier les scripts du mainteneur pour nettoyer le fichier obsolète, version-antérieure
doit être basé sur la version du package que vous préparez actuellement, et non sur la
première version du paquet qui n'avait pas le fichier de configuration. Ceci s'applique à tous les autres
actions de la même manière.

Par exemple, pour un fichier de configuration supprimé dans la version 2.0-1 d'un colis, version-antérieure
devrait être réglé sur 2.0-1~. Cela entraînera la suppression du fichier de configuration même si le
l'utilisateur a reconstruit la version précédente 1.0-1 as 1.0-1local1. Ou un forfait échangeant un
chemin d'accès à partir d'un lien symbolique (livré dans la version 1.0-1) dans un répertoire (livré en version
2.0-1), mais en n'effectuant le changement réel que dans les scripts du responsable de la version
3.0-1, devrait définir version-antérieure à 3.0-1~.

paquet
Le nom du package. Lorsque le package est « Multi-Arch : même » ce paramètre doit
inclure le qualificateur d'architecture, sinon il devrait pas comprennent généralement le
qualificateur d'architecture (car cela interdirait les reclassements ou le passage
architecture propre à l'architecture tous ou vice versa). Si le paramètre est
vide ou omis, le DPKG_MAINTSCRIPT_PACKAGE et DPKG_MAINTSCRIPT_ARCH
variables d'environnement (telles que définies par dpkg) sera utilisé pour générer un arch-qualifié
nom du paquet.

-- Tous les paramètres des scripts du mainteneur doivent être transmis au programme
après --.

CONFFILER S'INSCRIT TÂCHES

Lors de la mise à niveau d'un package, dpkg ne supprimera pas automatiquement un fichier de configuration (un fichier de configuration
fichier pour lequel dpkg devrait préserver les modifications de l'utilisateur) s'il n'est pas présent dans le nouveau
version. Il y a deux raisons principales à cela ; le premier est que le conffile aurait pu
été abandonné par accident et la prochaine version pourrait le restaurer, les utilisateurs ne voudraient pas que leur
changements jetés. La seconde est de permettre aux packages de transférer des fichiers à partir d'un
dpkg-maintained conffile dans un fichier maintenu par les scripts du mainteneur du paquet, généralement
avec un outil comme debconf ou ucf.

Cela signifie que si un paquet est destiné à renommer ou supprimer un fichier de configuration, il doit
le faire explicitement et dpkg-maintscript-helper peut être utilisé pour mettre en œuvre une suppression gracieuse
et le déplacement des fichiers de configuration dans les scripts du responsable.

Cette technologie permet de retirer toutes traces de maquillages ou bactéries. a fichier de configuration
Si un fichier de configuration est complètement supprimé, il doit être supprimé du disque, à moins que l'utilisateur n'ait
l'a modifié. S'il y a des modifications locales, elles doivent être conservées. Si le paquet
les mises à jour s'interrompent, le fichier de configuration nouvellement obsolète ne devrait pas disparaître.

Tout cela est implémenté en mettant l'extrait de shell suivant dans le préinst, post-installation
et après-midi scripts du responsable :

dpkg-maintscript-helper rm_conffile \
fichier de configuration version-antérieure paquet -- "$@"

fichier de configuration est le nom de fichier du fichier de configuration à supprimer.

Mise en œuvre actuelle : dans le préinst, il vérifie si le fichier de configuration a été modifié et renomme
c'est soit à fichier de configuration.dpkg-remove (si non modifié) ou à fichier de configuration.dpkg-sauvegarde (si
modifié). Dans le post-installation, ce dernier fichier est renommé en fichier de configuration.dpkg-bak et conservé pendant
référence car elle contient des modifications de l'utilisateur mais la première sera supprimée. Si le paquet
la mise à niveau s'interrompt, le après-midi réinstalle le fichier de configuration d'origine. Pendant la purge, le après-midi vont
supprimer également le .dpkg-bak dossier conservé jusqu'à présent.

Renommer a fichier de configuration
Si un fichier de configuration est déplacé d'un emplacement à un autre, vous devez vous assurer de vous déplacer
toute modification apportée par l'utilisateur. Cela peut sembler un simple changement de préinst script à
d'abord, cependant, l'utilisateur sera invité par dpkg approuver le conffile
modifications même s'ils n'en sont pas responsables.

Un renommage gracieux peut être implémenté en mettant l'extrait de shell suivant dans le
préinst, post-installation et après-midi scripts du responsable :

dpkg-maintscript-helper mv_conffile \
ancien-conffile nouveau-conffile version-antérieure paquet -- "$@"

ancien-conffile et nouveau-conffile sont l'ancien et le nouveau nom du fichier de configuration à renommer.

Mise en œuvre actuelle : la préinst vérifie si le fichier de configuration a été modifié, si oui c'est
laissé en place sinon il est renommé en ancien-conffile.dpkg-remove. Lors de la configuration, le
post-installation supprime ancien-conffile.dpkg-remove et renomme ancien-conffile à nouveau-conffile if vieux-
fichier de configuration est encore disponible. Lors de l'abandon de la mise à niveau/de l'abandon de l'installation, le après-midi renomme vieux-
fichier de configuration.dpkg-remove retour à ancien-conffile si nécessaire.

LIEN SYM ET ANNUAIRE INTERRUPTEURS

Lors de la mise à niveau d'un package, dpkg ne basculera pas automatiquement un lien symbolique vers un répertoire ou
vice versa. Les rétrogradations ne sont pas prises en charge et le chemin sera laissé tel quel.

Commutation a lien symbolique à annuaire
Si un lien symbolique est basculé vers un vrai répertoire, vous devez vous assurer avant de décompresser que
le lien symbolique est supprimé. Cela peut sembler un simple changement de préinst script au début,
Cependant, cela entraînera des problèmes en cas de personnalisation locale de l'administrateur du
lien symbolique ou lors de la rétrogradation du package.

Un renommage gracieux peut être implémenté en mettant l'extrait de shell suivant dans le
préinst, post-installation et après-midi scripts du responsable :

dpkg-maintscript-helper symlink_to_dir \
chemin d'accès ancienne cible version-antérieure paquet -- "$@"

chemin d'accès est le nom absolu de l'ancien lien symbolique (le chemin sera un répertoire à la fin
de l'installation) et ancienne cible est le nom cible de l'ancien lien symbolique à chemin d'accès.
Il peut être absolu ou relatif au répertoire contenant chemin d'accès.

Mise en œuvre actuelle : la préinst vérifie si le lien symbolique existe et pointe vers ancienne cible,
sinon, il est laissé en place, sinon il est renommé en chemin d'accès.dpkg-sauvegarde. Sur
configuration, le post-installation supprime chemin d'accès.dpkg-sauvegarde if chemin d'accès.dpkg-sauvegarde est encore
un lien symbolique. Lors de l'abandon de la mise à niveau/de l'abandon de l'installation, le après-midi renomme chemin d'accès.dpkg-sauvegarde retour à
chemin d'accès si nécessaire.

Commutation a annuaire à lien symbolique
Si un vrai répertoire est basculé vers un lien symbolique, vous devez vous assurer avant de décompresser que
le répertoire est supprimé. Cela peut sembler un simple changement de préinst script au début,
Cependant, cela entraînera des problèmes si le répertoire contient des fichiers de configuration,
chemins appartenant à d'autres packages, chemins créés localement ou lors de la rétrogradation du
paquet.

Une commutation gracieuse peut être implémentée en mettant l'extrait de shell suivant dans le
préinst, post-installation et après-midi scripts du responsable :

dpkg-maintscript-helper dir_to_symlink \
chemin d'accès nouvelle-cible version-antérieure paquet -- "$@"

chemin d'accès est le nom absolu de l'ancien répertoire (le chemin sera un lien symbolique à la fin
de l'installation) et nouvelle-cible est la cible du nouveau lien symbolique à chemin d'accès. Il peut
soit être absolu, soit relatif au répertoire contenant chemin d'accès.

Mise en œuvre actuelle : la préinst vérifie si le répertoire existe, ne contient pas
conffiles, les chemins appartenant à d'autres packages, ou les chemins créés localement, sinon alors
il est laissé en place, sinon il est renommé en chemin d'accès.dpkg-sauvegarde, et une mise en scène vide
répertoire nommé chemin d'accès est créé, marqué d'un fichier afin que dpkg puisse le suivre. Au
configuration, le post-installation termine le commutateur si chemin d'accès.dpkg-sauvegarde est toujours un
annuaire et chemin d'accès est le répertoire intermédiaire ; il supprime la marque du répertoire intermédiaire
fichier, déplace les fichiers nouvellement créés dans le répertoire intermédiaire vers la cible du lien symbolique
nouvelle-cible/, remplace le répertoire intermédiaire maintenant vide chemin d'accès avec un lien symbolique vers Nouveau-
l'objectif, et supprime chemin d'accès.dpkg-sauvegarde. Lors de l'abandon de la mise à niveau/de l'abandon de l'installation, le après-midi
renomme chemin d'accès.dpkg-sauvegarde retour à chemin d'accès si nécessaire.

INTÉGRATION IN FORFAITS

Lorsque vous utilisez un assistant d'emballage, veuillez vérifier s'il a natif dpkg-maintscript-helper
l'intégration, ce qui pourrait vous faciliter la vie. Voir par exemple dh_installdeb (1).

Étant donné que dpkg-maintscript-helper est utilisé dans le préinst, en l'utilisant inconditionnellement
nécessite une pré-dépendance pour garantir que la version requise de dpkg a été déballé
avant. La version requise dépend de la commande utilisée, par exemple rm_conffile et mv_conffile
il s'agit du 1.15.7.2, pour lien symbolique_to_dir et dir_to_symlink il est le 1.17.14 :

Pré-dépend : dpkg (>= 1.17.14)

Mais dans de nombreux cas, l'opération effectuée par le programme n'est pas critique pour le package, et
au lieu d'utiliser une pré-dépendance, nous ne pouvons appeler le programme que si nous savons que le
la commande requise est prise en charge par la commande actuellement installée dpkg:

si dpkg-maintscript-helper prend en charge commander; puis
dpkg-maintscript-helper commander ...
fi

La commande supports renverra 0 en cas de succès, 1 sinon. Les supports la commande sera
vérifier si les variables d'environnement définies par dpkg et requises par le script sont présentes,
et le considérera comme un échec au cas où l'environnement ne serait pas suffisant.

Utilisez dpkg-maintscript-helper en ligne à l'aide des services onworks.net