Ah non excusez-moi, on parle de mainteneurs qui ont patché des logiciels à l'insu des développeurs. Il faut forcément avoir un changelog spécifique aux bidouilles Debian.
Il y a deux types de patchs. Ceux qui corrigent des bugs amont, ou apportent des fonctionnalités, et qui doivent alors être remontés au projet amont, où ils peuvent être acceptés, refusés ou ignorés. Et il y a les patchs spécifiques à Debian, par exemple pour qu'on logiciel colle à la FHS, ou se conforme aux règles de Debian permettant de mettre en œuvre le multiarch, ou encore utilise des bibliothèques fournies par Debian au lieu de celles qu'il embarque normalement. Ces patchs-là n'ont aucune raison d'être envoyés au projet amont, où ils n'ont rien à faire.
Gné ? Que le serveur dise "j'ai la version 1.2.23" et que le client comprenne "tiens, j'ai la 1.2.21 sur mon ordi, il y a donc une nouvelle version" quand le client met à jour la liste des paquets des dépôts, ça nécessite de complexifier la procédure de création de paquet ?
Ben ça nécessite un fichier où écrire des choses comme (dans un cas simple) :
où se trouve l'index des version du logiciel ;
dans les noms des tarballs amont, où se trouve le numéro de version.
Cela doit aussi permettre de gérer des cas compliqués, avec par exemple des numéros de version amont qui doivent être transformés (par exemple parce qu'un jour, la numérotation amont a été modifiée de façon incompatible, et qu'heureusement Debian prévoit ce genre de cas avec un préfixe spécifique, qu'il faut alors ajouter), ou encore des archives à refaire à la volée pour en exclure quelques fichiers non libres.
Pour info, le fichier en question c'est debian/watch, utilisé par l'outil uscan (upstream scan).
la définition éventuelle des fichiers à mettre dans tel ou tel paquet binaire dans le cas d'une séparation en plusieurs paquets.
Là, je suis curieux d'avoir des cas pratiques.
Simple : OpenDKIM. C'est une mise en œuvre de la norme DKIM de signature de courrier életronique par les serveurs. Ce projet fournit deux choses, qui devraient pouvoir s'utiliser de façon indépendante :
un milter, c'est à dire un démon auquel un serveur de courrier va déléguer la tâche de signature ou de vérification des messages ;
des outils de génération de clefs et de test.
Ça tombe bien, dans Debian ils ont été séparés en deux paquets.
Autre cas d'usage, GRUB 2. Sous Debian, il a été séparé en plusieurs paquets, de sorte qu'on peut installer par exemple les bibliothèques et outils de GRUB pour PC et pour EFI amd64 (dans le but de réaliser des clefs USB démarrables pour ces deux plate-formes), et installer localement seulement GRUB pour PC comme chargeur de démarrage.
Enfin, c'est très utile pour la mise en œuvre d'installations simultanées de logiciels pour plusieurs architectures, mais c'est un vaste sujet.
[^] # Re: Mouaif
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 7. Dernière modification le 09 septembre 2014 à 10:50.
Il y a deux types de patchs. Ceux qui corrigent des bugs amont, ou apportent des fonctionnalités, et qui doivent alors être remontés au projet amont, où ils peuvent être acceptés, refusés ou ignorés. Et il y a les patchs spécifiques à Debian, par exemple pour qu'on logiciel colle à la FHS, ou se conforme aux règles de Debian permettant de mettre en œuvre le multiarch, ou encore utilise des bibliothèques fournies par Debian au lieu de celles qu'il embarque normalement. Ces patchs-là n'ont aucune raison d'être envoyés au projet amont, où ils n'ont rien à faire.
Ben ça nécessite un fichier où écrire des choses comme (dans un cas simple) :
Cela doit aussi permettre de gérer des cas compliqués, avec par exemple des numéros de version amont qui doivent être transformés (par exemple parce qu'un jour, la numérotation amont a été modifiée de façon incompatible, et qu'heureusement Debian prévoit ce genre de cas avec un préfixe spécifique, qu'il faut alors ajouter), ou encore des archives à refaire à la volée pour en exclure quelques fichiers non libres.
Pour info, le fichier en question c'est
debian/watch, utilisé par l'outiluscan(upstream scan).Simple : OpenDKIM. C'est une mise en œuvre de la norme DKIM de signature de courrier életronique par les serveurs. Ce projet fournit deux choses, qui devraient pouvoir s'utiliser de façon indépendante :
Ça tombe bien, dans Debian ils ont été séparés en deux paquets.
Autre cas d'usage, GRUB 2. Sous Debian, il a été séparé en plusieurs paquets, de sorte qu'on peut installer par exemple les bibliothèques et outils de GRUB pour PC et pour EFI amd64 (dans le but de réaliser des clefs USB démarrables pour ces deux plate-formes), et installer localement seulement GRUB pour PC comme chargeur de démarrage.
Enfin, c'est très utile pour la mise en œuvre d'installations simultanées de logiciels pour plusieurs architectures, mais c'est un vaste sujet.