Dès le début c'est folklorique! D'abord il faut que je renomme la tarball. (Mais pourquoi? Peut-être pour éviter d'écrire le numéro de version dans le fichier de configuration?)
Pour qu'ils soient faciles à identifier dans l'archive Debian ? Les développeurs amont n'ayant pas de convention uniforme pour nommer leurs archives, Debian normalise cela. Personnellement je trouve cela agréable, ainsi en téléchargeant des paquets sources on se retrouve avec des noms cohérents dont chacun suffit à identifier : de quel paquet il s'agit, et de quelle version de ce paquet il s'agit. Laisser les noms des archives amont aurait des avantages et des inconvénients, mais renomment un fichier est si facile qu'il me semble spécieux d'arguer sur ce point précis.
Ensuite je dois exploser la tarball et travailler dans le dossier des sources, où je crée un dossier debian qui contient mon petit krims-krams de packageur. On voit tout de suite l'avantage de ce système:
Oui, l'avantage c'est que c'est naturel. On bosse dans le répertoire des sources, après tout c'est là qu'on fait la compilation.
comme mon krims-krams est en RCS
Bon, je vais me forcer à continuer à lire malgré cet archaïsme ahurissant.
je dois faire un checkout à chaque fois que je fais une mise-à-jour du système, et si par hasard j'ai choisi git...
Si par hasard tu as choisi Git, c'est parfait. C'est ce que j'utilise, et ça marche très bien : si les développeurs amont utilisent aussi Git tu mets ton répertoires source (amont + répertoire debian/) dans une branche qui en dérive, et s'ils n'utilisent pas Git tu fais pareil sauf que c'est toi qui crées la branche amont à partir des tarballs qu'ils fournissent.
Du coup, la meuilleure stratégie est sûrement de symlinker le dossier debian vers le dossier adéquat de ma copie de travail contenant tous mes trucs de packageurs.
Probablmenet pas non. La meilleure stratégie est à mon avis de versionner le tout (sources amont + répertoire debian/), mais certains préfèrent effectivement ne versionner que leur travail d'empaquetage, ce qui nécessite d'utiliser des scripts spécifiques pour cela. Personnellement je n'aime pas du tout cela, à cause du côté artificiel lié à l'utilisation de ces scripts.
Ensuite je dois écrire un 9 dans le dossier debian/compat. Qui ne contient que cette seule donnée.
Ça s'appelle du versionnement de format, tu trouveras ça dans plein de trucs, même dans le format tar tiens.
Ensuite il faut que je crée un ChangeLog contenant le numéro de ticket où j'ai annoncé au monde entier que j'allais écrire un package.
Ça, ce n'est pas pour t'embêter mais pour te simplifier la vie : quand tu enverras ton paquet, ça ira automatiquement fermer le pseudo-bug correspondant à ton annonce d'empaquetage. Quant au fait d'avoir un changelog d'empaquetage, ça n'a rien d'anormal.
Bon, je le remplirai quand j'aurais fini, mais ça serait quand-même plus simple si mes fichiers de packagers soient sous RCS et que tout le monde puisse regarder le log de ces fichiers...
Encore RCS ? Bon, alors, déjà, que ce soit clair : le format de paquets de Debian est indépendant des systèmes de gestion de version, et heureusement, parce que sinon on risquerait d'être coincés avec des vieilleries comme justement RCS, ou de se voir imposer Mercurial alors qu'on préfère Git... Mais toujours est-il que, pour faciliter la vie des gens qui utilisent des systèmes de gestion de version pour leur empaquetage, il existe justement des outils qui remplissent automatiquement le changelog Debian à partir de celui du gestionnaire de version. Enfin, ça existe pour les systèmes de versionnement actuels, mais pour RCS c'est peu probable.
Ensuite il faut que j'écrive un fichier rules qui est un GNU Makefile, un peu à la FreeBSD en somme. Sauf que là je dois le replir avec une incantation vaudoo un peu moins parlante que .include :
Alors, ce fichier rules, c'est effectivement un Makefile, qui doit avoir des cibles précises, genre binary, build, clean, etc. (c'est documenté dans la charte Debian). Si tu veux les écrire toi-même, en indiquant ce qu'il faut faire pour chaque étape, tu peux. Sinon tu peux utiliser la syntaxe que tu mentionne, qui délègue toutes les étapes à dh, un ensemble de scripts prévus pour essayer toutes les méthodes connues avec les systèmes de constructions usuels. Et sinon, tu peux aussi utiliser CDBS, un système à base d'include comme tu as l'air d'aimer.
Après quelques hésitations on arrive enfin à un truc qui marche à peu près, mais on croit avoir tout bien fait et lintian nous crache une page d'insultes à la gueule — désolé j'ai recopié l'exemple du livre moi!
Ah, mais c'est qu'il ne suffit pas de faire un paquet qui marche, il faut faire un paquet propre, notamment correctement documenté et respectant les conventions, par exemple la FHS. Si c'est tout ce que tu avais fait, il manquait notamment le fichier debian/copyright décrivant la ou les licences utilisées dans ce paquet.
Pourquoi est-ce que c'est aussi compliqué et aussi mal expliqué sous Debian, alors que c'est simple et clair ailleurs?
Compliqué, parce qu'on veut faire quelque chose de propre, solide et bien documenté, et que s'il suffisait pour cela de compiler le logiciel amont, ça se saurait. Debian existe pour uniformiser un système, et ça demande des efforts, sinon il n'y aurait pas de distribution.
Mal expliqué, ça c'est un autre problème, sur lequel on peut aider.
# Point par point
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 10.
Pourquoi ? Soit, voyons ça point par point.
Pour qu'ils soient faciles à identifier dans l'archive Debian ? Les développeurs amont n'ayant pas de convention uniforme pour nommer leurs archives, Debian normalise cela. Personnellement je trouve cela agréable, ainsi en téléchargeant des paquets sources on se retrouve avec des noms cohérents dont chacun suffit à identifier : de quel paquet il s'agit, et de quelle version de ce paquet il s'agit. Laisser les noms des archives amont aurait des avantages et des inconvénients, mais renomment un fichier est si facile qu'il me semble spécieux d'arguer sur ce point précis.
Oui, l'avantage c'est que c'est naturel. On bosse dans le répertoire des sources, après tout c'est là qu'on fait la compilation.
Bon, je vais me forcer à continuer à lire malgré cet archaïsme ahurissant.
Si par hasard tu as choisi Git, c'est parfait. C'est ce que j'utilise, et ça marche très bien : si les développeurs amont utilisent aussi Git tu mets ton répertoires source (amont + répertoire debian/) dans une branche qui en dérive, et s'ils n'utilisent pas Git tu fais pareil sauf que c'est toi qui crées la branche amont à partir des tarballs qu'ils fournissent.
Probablmenet pas non. La meilleure stratégie est à mon avis de versionner le tout (sources amont + répertoire debian/), mais certains préfèrent effectivement ne versionner que leur travail d'empaquetage, ce qui nécessite d'utiliser des scripts spécifiques pour cela. Personnellement je n'aime pas du tout cela, à cause du côté artificiel lié à l'utilisation de ces scripts.
Ça s'appelle du versionnement de format, tu trouveras ça dans plein de trucs, même dans le format tar tiens.
Ça, ce n'est pas pour t'embêter mais pour te simplifier la vie : quand tu enverras ton paquet, ça ira automatiquement fermer le pseudo-bug correspondant à ton annonce d'empaquetage. Quant au fait d'avoir un changelog d'empaquetage, ça n'a rien d'anormal.
Encore RCS ? Bon, alors, déjà, que ce soit clair : le format de paquets de Debian est indépendant des systèmes de gestion de version, et heureusement, parce que sinon on risquerait d'être coincés avec des vieilleries comme justement RCS, ou de se voir imposer Mercurial alors qu'on préfère Git... Mais toujours est-il que, pour faciliter la vie des gens qui utilisent des systèmes de gestion de version pour leur empaquetage, il existe justement des outils qui remplissent automatiquement le changelog Debian à partir de celui du gestionnaire de version. Enfin, ça existe pour les systèmes de versionnement actuels, mais pour RCS c'est peu probable.
Alors, ce fichier rules, c'est effectivement un Makefile, qui doit avoir des cibles précises, genre binary, build, clean, etc. (c'est documenté dans la charte Debian). Si tu veux les écrire toi-même, en indiquant ce qu'il faut faire pour chaque étape, tu peux. Sinon tu peux utiliser la syntaxe que tu mentionne, qui délègue toutes les étapes à dh, un ensemble de scripts prévus pour essayer toutes les méthodes connues avec les systèmes de constructions usuels. Et sinon, tu peux aussi utiliser CDBS, un système à base d'include comme tu as l'air d'aimer.
Ah, mais c'est qu'il ne suffit pas de faire un paquet qui marche, il faut faire un paquet propre, notamment correctement documenté et respectant les conventions, par exemple la FHS. Si c'est tout ce que tu avais fait, il manquait notamment le fichier debian/copyright décrivant la ou les licences utilisées dans ce paquet.
Compliqué, parce qu'on veut faire quelque chose de propre, solide et bien documenté, et que s'il suffisait pour cela de compiler le logiciel amont, ça se saurait. Debian existe pour uniformiser un système, et ça demande des efforts, sinon il n'y aurait pas de distribution.
Mal expliqué, ça c'est un autre problème, sur lequel on peut aider.