La licence ? Et quand il y en a plusieurs ? Quand il y a un fichier qui est sous une licence distincte ? Quand l'empaqueteur ne peut pas licencier son travail de la même façon (projet amont dans le domaine public et empaqueteur en France par exemple) ?
le suivi des versions du logiciel amont et des révisions de l'empaquetage, avec lien avec le système de suivi de bugs de la distribution
Les ports MacPorts sont gérés dans un repository Subversion, donc en examinant les commit logs du Portfile j'ai une correspondance claire entre les révisions du Portfile et les versions upstream.
Le lien avec le système de suivi de bogues de la distribution est fait par trac cela ressemble à ca:
[...]
Est-ce que ça suffit?
À condition d'aimer Subversion, oui. Je suis pour ma part heureux que Debian n'impose pas d'utiliser ce système que j'aime de moins en moins.
avec automatisation du téléchargement et de leur intégration dans ton empaquetage
Je ne suis pas sûr de comprendre à quoi tu fais référence, mais j'ai l'impression que c'est une fonction qui n'a de sens ou d'utilité que pour un maintainer Debian.
En effet, ça s'adresse aux mainteneurs Debian qui ne sont pas également développeurs amont, ces derniers étant forcément les premiers au courant de leurs nouvelles versions. Mais pas seulement : c'est également utilisé par des outils automatiques de la plate-forme de qualité de Debian, pour réaliser des rapports agrégés, par exemple sur tous les paquets dont s'occupe Untel, en indiquant notamment lesquels sont en retard sur la version amont.
Ça permet en une commande de vérifier s'il y a une nouvelle version amont, de la télécharger et de la renommer pour qu'elle colle à la nomenclature Debian. Et ça permet également, au besoin, de la ré-empaqueter, par exemple si elle est fournie au format ZIP (il faut un tarball) ou si elle contient des fichiers non libres (qu'il faut alors retirer).
la définition éventuelle des fichiers à mettre dans tel ou tel paquet binaire dans le cas d'une séparation en plusieurs paquets
Ce n'est pas pris en charge par MacPorts à ma connaissance mais d'une part je n'ai pas utilisé cette fonction dans la préparation de mon package Debian et c'était quand-même compliqué
Oui, c'est compliqué, et inutile dans les cas simples. Mais cela permet par exemple de séparer le milter OpenDKIM des outils OpenDKIM, permettant ainsi aux utilisateurs d'installer de quoi générer des clefs DKIM sans avoir à installer le serveur de signature et d'analyse de messages.
Dans les systèmes de ports du monde BSD, soit FreeBSD, NetBSD, OpenBSD et MacPorts je crois savoir que celui de FreeBSD est le plus mal fichu de tous — mais n'ayant pas utilisé ni NetBSD ni OpenBSD, il faut mettre de très gros guillemets autour de mon "je crois savoir" — et pourtant il est bien plus accessible pour le maintainer que le système de packages de Debian à cause d'une bonne documentation bien à jour.
Le système d'empaquetage de Debian est complexe, il n'y a rien à dire à ce sujet. Mais les tâches sont plutôt bien séparées, et en commençant avec un paquet pas trop compliqué (genre pas un démon qui nécessite de la configuration de la part de l'utilisateur), je ne pense pas qu'il soit trop difficile de débuter, à condition de s'intéresser sérieusement à Debian (l'empaquetage Debian par un développeur amont qui n'utilise pas Debian ou seulement de façon occasionnelle, on peut oublier, c'est clair), et cela se retient plutôt bien. La documentation est un problème, d'où la récente page du wiki Debian je crois. Et sinon, il ne faut pas hésiter à demander sur le salon IRC qui va bien (#debian-mentors sur OFTC).
[^] # Re: Mouaif
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 5.
La licence ? Et quand il y en a plusieurs ? Quand il y a un fichier qui est sous une licence distincte ? Quand l'empaqueteur ne peut pas licencier son travail de la même façon (projet amont dans le domaine public et empaqueteur en France par exemple) ?
À condition d'aimer Subversion, oui. Je suis pour ma part heureux que Debian n'impose pas d'utiliser ce système que j'aime de moins en moins.
En effet, ça s'adresse aux mainteneurs Debian qui ne sont pas également développeurs amont, ces derniers étant forcément les premiers au courant de leurs nouvelles versions. Mais pas seulement : c'est également utilisé par des outils automatiques de la plate-forme de qualité de Debian, pour réaliser des rapports agrégés, par exemple sur tous les paquets dont s'occupe Untel, en indiquant notamment lesquels sont en retard sur la version amont.
Ça permet en une commande de vérifier s'il y a une nouvelle version amont, de la télécharger et de la renommer pour qu'elle colle à la nomenclature Debian. Et ça permet également, au besoin, de la ré-empaqueter, par exemple si elle est fournie au format ZIP (il faut un tarball) ou si elle contient des fichiers non libres (qu'il faut alors retirer).
Oui, c'est compliqué, et inutile dans les cas simples. Mais cela permet par exemple de séparer le milter OpenDKIM des outils OpenDKIM, permettant ainsi aux utilisateurs d'installer de quoi générer des clefs DKIM sans avoir à installer le serveur de signature et d'analyse de messages.
Le système d'empaquetage de Debian est complexe, il n'y a rien à dire à ce sujet. Mais les tâches sont plutôt bien séparées, et en commençant avec un paquet pas trop compliqué (genre pas un démon qui nécessite de la configuration de la part de l'utilisateur), je ne pense pas qu'il soit trop difficile de débuter, à condition de s'intéresser sérieusement à Debian (l'empaquetage Debian par un développeur amont qui n'utilise pas Debian ou seulement de façon occasionnelle, on peut oublier, c'est clair), et cela se retient plutôt bien. La documentation est un problème, d'où la récente page du wiki Debian je crois. Et sinon, il ne faut pas hésiter à demander sur le salon IRC qui va bien (#debian-mentors sur OFTC).