Je suis justement en train d'écrire depuis plusieurs mois une doc sur la création de paquetage pour Debian, basé sur les autotools. C'est clair que ça n'est pas simple. Je vois deux principales raisons à ça : l'historique de Debian, qui est quand même une des plus anciennes distros, et le fait que Debian avant tout une communauté de gens qui s'accordent selon des principes démocratiques avant d'être une solution technique.
Le premier point doit être la raison des fichiers un peu en vrac (car je ne connais pas leur histoire exacte) : c'est clair que ça n'est pas « propre » comme le voudraient certains esthètes, mais c'est de toute façon géré automatiquement aujourd'hui pour la plupart. Les fichiers essentiels à connaître son décrits ici : https://www.debian.org/doc/manuals/maint-guide/dreq.fr.html. D'ailleurs, c'est la doc officielle du mainteneur, et je la trouve plutôt bien faite, en plus d'être traduite en français : https://www.debian.org/doc/manuals/maint-guide/index.fr.html. Le wiki, c'est vraiment une source pas terrible selon moi (oui, je suis en train de tendre le bâton pour me faire battre).
Les fichiers requis ont (à peu près) tous une raison valable d'exister : le control c'est celui qui correspond le mieux à ce qui existe dans les autres distros pour « définir » le paquet ; le copyright est séparé car historiquement non-structuré, contrairement au control, même si ça n'est plus le cas aujourd'hui (mais pour cause de rétro-compatibilité, on peut faire soit l'un soit l'autre) ; le changelog c'est parce qu'historiquement, on n'avait pas de VCS, et puis il est utilisé par plein d'outils pour en extraire des informations (comme la version : ainsi, le fichier contrôle qui définit l'identité du paquet change peu) ; et le fichier rules est séparé du control car celui-ci n'est pas descriptif, mais est un ensemble de commandes. On pourrait essayer d'en réunir certains, mais je ne vois pas de raisons très convaincantes.
La rétro-compatibilité, c'est très important, même si c'est chiant : ce sont souvent les empaqueteurs « jeunes » qui vont râler sur tous ces archaïsmes qui viennent les embêter. Mais avec l'âge, on apprend que certains de ceux-ci (pas tous, hein), et le principe de rétro-compatibilité, sont vraiment très importants.
Ce qui est aussi très important dans Debian, c'est la conformance à ses standards sur la liberté du code : c'est une des raisons de la normalisation du noms des paquets sources, car ceux-ci peuvent aussi être retravaillés s'ils contiennent des morceaux qui ne respectent pas la charte (les sources sont appelées dfsg-free pour "Debian Free Software guidelines"-free). C'est un point très important également pour la distribution : Debian possède un réseau de distribution assez gigantesque et pourtant gratuit pour l'utilisateur, car les personnes (les ftpmaster) qui le font ont confiance dans la légalité de ce que fait le projet.
La deuxième raison est celle qui fait qu'il y a 40 manière de faire chaque chose dans Debian : beaucoup de monde a une idée différente de comment « bien » faire les choses, et du coup, soit on s'accorde sur une méthode commune (genre la gestion unifée des patchs dans le format 3.0, lancée par Raphaël Hertzog qui traîne ici), soit on trouve une manière de faire cohabiter « pacifiquement » les différentes méthodes (comme le fait que les mainteneurs ont des préférences de VCS différentes, même si j'ai l'impression que git domine ; bon, c'est justement un peu ce qu'a permis le passage au format 3.0). C'est plus compliqué quand les gens n'arrivent pas à s'accorder, mais on ne peut pas (ou rarement) avoir recours à des méthodes autoritaires pour décider d'une seule et unique manière de faire quand on est une communauté régie par une constitution. Ça ne va pas plaire aux « pragmatiques » du coin, mais moi je trouve ça très pragmatique au contraire.
C'est cette vision démocratique qui fait aussi que l'historique a l'air parfois un peu inconsistant : le projet évolue au fur et à mesure de sa vie, et les standards changent d'une époque à l'autre. Malgré tout ça, je trouve que le projet Debian se porte plutôt bien, et est reconnu pour la qualité des ses paquets, à défaut de sa célérité d'empaquetage. Je pense que c'est dû très largement à sa manière de voir le but du projet comme un objet social et politique plutôt que de se concentrer sur la partie technique (même si elle est pourtant très reconnue).
Les méthodes d'empaquetage pour d'autres projets ont beau être techniquement « supérieure », je ne suis pas sûr que ça tienne complètement sur le long terme sans objectif moins technique : j'ai souvenir que le standard il y a dix ans sous MacOS X c'était fink. Je suppose que ça a changé vu que je n'entends plus parler que de MacPorts les quelques fois où je rencontre ce genre de packaging (et à l'époque MacPorts n'était pas terrible). Un autre « mauvais » exemple est OpenWrt : je trouve le système de packaging vraiment génial, mais la communauté derrière est assez désordonnée et mal organisée, ce qui fait que le projet est toujours un peu vacillant (et pourtant j'adore ce qu'ils font). Bref, se concentrer sur la technique, c'est oublier un aspect très important du logiciel libre.
# C'est l'histoire et la démocratie
Posté par benoar . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 10.
Je suis justement en train d'écrire depuis plusieurs mois une doc sur la création de paquetage pour Debian, basé sur les autotools. C'est clair que ça n'est pas simple. Je vois deux principales raisons à ça : l'historique de Debian, qui est quand même une des plus anciennes distros, et le fait que Debian avant tout une communauté de gens qui s'accordent selon des principes démocratiques avant d'être une solution technique.
Le premier point doit être la raison des fichiers un peu en vrac (car je ne connais pas leur histoire exacte) : c'est clair que ça n'est pas « propre » comme le voudraient certains esthètes, mais c'est de toute façon géré automatiquement aujourd'hui pour la plupart. Les fichiers essentiels à connaître son décrits ici : https://www.debian.org/doc/manuals/maint-guide/dreq.fr.html. D'ailleurs, c'est la doc officielle du mainteneur, et je la trouve plutôt bien faite, en plus d'être traduite en français : https://www.debian.org/doc/manuals/maint-guide/index.fr.html. Le wiki, c'est vraiment une source pas terrible selon moi (oui, je suis en train de tendre le bâton pour me faire battre).
Les fichiers requis ont (à peu près) tous une raison valable d'exister : le
controlc'est celui qui correspond le mieux à ce qui existe dans les autres distros pour « définir » le paquet ; lecopyrightest séparé car historiquement non-structuré, contrairement aucontrol, même si ça n'est plus le cas aujourd'hui (mais pour cause de rétro-compatibilité, on peut faire soit l'un soit l'autre) ; lechangelogc'est parce qu'historiquement, on n'avait pas de VCS, et puis il est utilisé par plein d'outils pour en extraire des informations (comme la version : ainsi, le fichier contrôle qui définit l'identité du paquet change peu) ; et le fichierrulesest séparé ducontrolcar celui-ci n'est pas descriptif, mais est un ensemble de commandes. On pourrait essayer d'en réunir certains, mais je ne vois pas de raisons très convaincantes.La rétro-compatibilité, c'est très important, même si c'est chiant : ce sont souvent les empaqueteurs « jeunes » qui vont râler sur tous ces archaïsmes qui viennent les embêter. Mais avec l'âge, on apprend que certains de ceux-ci (pas tous, hein), et le principe de rétro-compatibilité, sont vraiment très importants.
Ce qui est aussi très important dans Debian, c'est la conformance à ses standards sur la liberté du code : c'est une des raisons de la normalisation du noms des paquets sources, car ceux-ci peuvent aussi être retravaillés s'ils contiennent des morceaux qui ne respectent pas la charte (les sources sont appelées dfsg-free pour "Debian Free Software guidelines"-free). C'est un point très important également pour la distribution : Debian possède un réseau de distribution assez gigantesque et pourtant gratuit pour l'utilisateur, car les personnes (les ftpmaster) qui le font ont confiance dans la légalité de ce que fait le projet.
La deuxième raison est celle qui fait qu'il y a 40 manière de faire chaque chose dans Debian : beaucoup de monde a une idée différente de comment « bien » faire les choses, et du coup, soit on s'accorde sur une méthode commune (genre la gestion unifée des patchs dans le format 3.0, lancée par Raphaël Hertzog qui traîne ici), soit on trouve une manière de faire cohabiter « pacifiquement » les différentes méthodes (comme le fait que les mainteneurs ont des préférences de VCS différentes, même si j'ai l'impression que git domine ; bon, c'est justement un peu ce qu'a permis le passage au format 3.0). C'est plus compliqué quand les gens n'arrivent pas à s'accorder, mais on ne peut pas (ou rarement) avoir recours à des méthodes autoritaires pour décider d'une seule et unique manière de faire quand on est une communauté régie par une constitution. Ça ne va pas plaire aux « pragmatiques » du coin, mais moi je trouve ça très pragmatique au contraire.
C'est cette vision démocratique qui fait aussi que l'historique a l'air parfois un peu inconsistant : le projet évolue au fur et à mesure de sa vie, et les standards changent d'une époque à l'autre. Malgré tout ça, je trouve que le projet Debian se porte plutôt bien, et est reconnu pour la qualité des ses paquets, à défaut de sa célérité d'empaquetage. Je pense que c'est dû très largement à sa manière de voir le but du projet comme un objet social et politique plutôt que de se concentrer sur la partie technique (même si elle est pourtant très reconnue).
Les méthodes d'empaquetage pour d'autres projets ont beau être techniquement « supérieure », je ne suis pas sûr que ça tienne complètement sur le long terme sans objectif moins technique : j'ai souvenir que le standard il y a dix ans sous MacOS X c'était fink. Je suppose que ça a changé vu que je n'entends plus parler que de MacPorts les quelques fois où je rencontre ce genre de packaging (et à l'époque MacPorts n'était pas terrible). Un autre « mauvais » exemple est OpenWrt : je trouve le système de packaging vraiment génial, mais la communauté derrière est assez désordonnée et mal organisée, ce qui fait que le projet est toujours un peu vacillant (et pourtant j'adore ce qu'ils font). Bref, se concentrer sur la technique, c'est oublier un aspect très important du logiciel libre.