Guide de mise à jour des ports pour le mainteneur

Depuis OpenBSD 3.8, pkg_add est capable de mettre à jour les paquetages. Cependant, les mainteneurs doivent être conscient d'un simple fait : une mise à jour n'est pas instantanée. Même si un utilisateur passe d'une version d'OpenBSD à l'autre, à chaque fois qu'ils lanceront pkg_add -ui le système remplacera chaque paquetage avec une nouvelle version, un par un. Cela signifie que l'utilisateur se retrouvera à faire tourner un système mixte, même si ce n'est que pour quelques minutes.

Il y a en gros deux modèles de mise à jour dont les mainteneurs doivent être conscients.

• Certains utilisateurs suivent "current" de manière assez régulière. Ils mettent à jour leurs paquetages tous les quelques jours/semaines ; soit tous les paquetages, soit certains sélectionnés. Le mécanisme de mise à jour devrait fonctionner pour eux : il peut les forcer à mettre à niveau certains paquetages ou à en installer de nouveaux mais il ne devrait pas échouer silencieusement. Les toutes petites mises à jour doivent être testées. Ces utilisateurs seront à même de gérer certains changements tels que le renommage d'un programme ou des ajustements dans la configuration de celui-ci.
• Certains utilisateurs mettent à jour tous les six mois à chaque nouvelle version. Ils téléchargeront également les mises à jour stables (mise à jour critiques et de sécurité). Pendant six mois, une grande partie de l'arbre des ports va changer. Ces utilisateurs se moquent des changements individuels à chaque programme. Ils souhaitent juste un système fonctionnel. Changer le nom des binaires est assez traumatisant pour ces utilisateurs. Ajuster des centaines de fichier de configuration leurs sera également très douloureux. Les mainteneurs peuvent aider à créer des mise à jour fluides et à donner des conseils dès que quelque chose d'important aura changé.

Il faut bien noter qu'une partie du processus de mise à jour, spécialement lors des grosses mises à niveau bi-anuelles, n'est pas encore automatisée. Le mécanisme de mise à niveau reste en cours de développement et pkg_add sera capable de résoudre de plus en plus de problèmes dans le futur. A l'heure actuelle, vous devriez vous concentrer sur le bon fonctionnement des mises à jour, un port à la fois, en vérifiant que celle-ci prenne bien les autres ports en considération pour tout ce qui concerne les conflits et problèmes éventuels.

Nommage des paquetages et procédure de mise à niveau

Conflits, mettre en place un plan pour le futur

Le problème des renommages et des branches

Fichiers de configuration et mises à jour

Le problème des librairies partagées

Liste de vérifications pour la mise à jour

• Faites en sorte que les auteurs du programme soient au courant des changements nécessaires à son fonctionnement sous OpenBSD. Vous devez faire en sorte que les patches soient intégrés dans la prochaine version du logiciel. Sinon, il faut vous préparer à réécrire la plupart des patches à chaque nouvelle version.
• Faites en sorte que les auteurs du programme comprennent la numérotation des versions. Si les distfiles ne contiennent pas de numéro de version ou si elles ne référencent que la plus récente, prenez contact avec l'auteur afin d'obtenir une URL permanente.
• Documentez les différentes astuces nécessaires au bon fonctionnement du port. Cela permettra de vérifier si elles sont toujours nécessaires lorsque vous mettrez à jour le port en question.
• Documentez les dépendances, spécialement pour ce que vous n'utilisez pas. Certains logiciels peuvent utiliser des programmes externes qui ne sont pas forcément disponibles au moment de la création du port, soyez donc certains de ne pas en activer le support et documentez le afin de pouvoir mettre votre port à jour au moment où ce logiciel deviendra disponible.
• Si le port utilise libtool, utilisez son log comme base pour votre configuration SHARED_LIBS. Cela facilitera les mises à jour.
• Utilisez PLIST_DB et construisez une base de données de packing-lists. Cela est utile pour découvrir les paquetages ayant besoin d'une révision du PKGNAME ainsi que pour trouver les conflits avec d'anciens paquetages.
• Faites en sorte que les dépendances soient les moins lourdes possibles. Par défaut, RUN_ et LIB_DEPENDS se satisferont de n'importe quelle version d'un paquetage. N'insistez pas sur une version particulière à moins que cela ne soit pas possible autrement. Utilisez les numéros de versions minimums lorsque cela est possible.

• Chaque mise à jour de port doit se voir augmenter son numéro de version ("package name bump"). Dans le cas contraire, le processus de mise à jour ne fonctionnera pas. Chaque changement entrainant un changement de binaire du paquetage entraine un "package bump". Cela inclu le changement de HOMEPAGE, MAINTAINER ou la description.
• Si le paquetage ne compile pas, aucun "bump" n'est nécessaire : un changement permettant de remettre un port en état de compiler (et de fonctionner) ne nécessite pas d'incrémenter son numéro de version.
• Les changements faisant en sorte qu'un port ne détecte pas une dépendance externe entrainent un incrément.
• Les changements dans les dépendances n'affectent généralement pas le numéro de version. Le système de paquetage utilise un mécanisme de signature identifiant un paquetage binaire par son nom, les dépendances avec lesquelles il a été compilé ainsi que le numéro de version des bibliothèques partagées qu'il contient.

• lancez make patch afin d'avoir une copie initiale du port avant la mise à jour.

• Editez le Makefile du port afin de récupérer la nouvelle version, lancez make makesum et make patch en guise de démarrage.
• Une fois que vous aurez réparé les patches ayant échoués, lancez un diff complet entre l'ancienne et la nouvelle version afin de voir exactement ce qui a changé. Prenez des notes et préparez-vous à arranger certaines choses par la suite.
• Faites ce qu'il faut afin que la nouvelle version tourne sous OpenBSD, ajustez les dépendances, changez le contenu des paquetages etc.
• Vérifiez bien les versions des bibliothèques partagées. Pour les ports basés sur libtool, vous aurez un fichier shared_libs.log qui vous permettra de vérifier si les auteurs du logiciel ont effectué des changements significatifs. Notez bien que cela ne suffit pas. La plupart des développeurs de logiciels ne sont pas à l'aide avec les bibliothèques partagées. Vous devez lire le diff complet entre l'ancienne et la nouvelle version et augmenter la version des bibliothèques en conséquence. Si vous avez un doute, augmentez la version majeure.
• Faites attention au conflits avec les paquetages déja compilés. Pour des mises à jour simples, il n'y a rien besoin de faire. Si vous séparez le paquetage en différents sous-paquetages ("subpackages"), soyez certains que ceux-ci possèdent les annotations de conflit : ils devraient généralement entrer en conflit avec l'ancien paquetage non découpé.
• Aidez l'utilisateur : si certaines étapes sont nécessaires en plus de pkg_add -ui, faites en sorte qu'elles soient visibles dans le paquetage. Lorsque votre politique de packaging change, documentez-la dans la description de celui-ci. Par exemple, si vous déplacez la documentation vers un paquetage séparé afin de gagner de l'espace, la description du paquetage principal devrait mentionner que la documentation est à présent disponible dans un paquetage séparé.