Suite à certains commentaires sur LinuxFR qui attaquaient le travail des responsables Debian chargés de la maintenance d’applications qui sont fournies sous forme de paquets, j’ai pensé qu’une petite mise au point (et accessoiremment le point de vue d’un de ces responsables :)) pourrait vous intéresser.
Les développeurs des applications que l’on retrouve dans l’archive officielle ne sont souvent pas des administrateurs système chevronnés. Il se peut même qu’en programmation ils soient des débutants qui ont produit un projet qui tient bien la route et rencontre le succès (je le souhaite à tous ceux qui voudraient tenter l’aventure) dès le premier essai. Mais dans ce cas il est évident et bien compréhensible qu’ils ignorent certains aspects système et sécurité qui pourtant sont très importants lorsqu’on incorpore son logiciel dans une distribution. Le responsable/développeur Debian qui va produire le paquet Debian de l’application va, lui, voir ces défauts apparaître comme le nez au milieu de la figure.
La responsabilité du responsable/développeur Debian est également engagé car c’est lui qui prend la responsabilité d’inclure le logiciel dans la distribution. Le programme contenu dans le paquet peut donc nécessiter des modifications pour correctement s’insérer au sein de la collection des 39000 paquets proposés par Debian à ce jour. Ces modifications permettent d’adapter le logiciel au fonctionnement de Debian afin, par exemple, de vous assurer que votre logiciel sera correctement mis à jour quand trois ans plus tard vous aurez l’idée de le mettre à jour. N’oublions pas également de signaler que ce même responsable fournira du support à tous ceux qui lui signalent un problème gratuitement et bien souvent sur son temps libre.
Oui un individu qui code dans son coin et qui pond un programme a le plus souvent besoin de conseils pour bien s’insérer au niveau système. C’est pour ça que easy_install/pip/rubygem/cpan sont des logiciels d’installation automatisée qui rendent des services mais restent du quick&dirty pour les développeurs pressés sur des bécanes de développement. Aptitude quant à lui assure que tous vos programmes seront mis à jour lorsque votre distribution évolue. C’est un paramètre dont le développeur se fiche, mais pas l’administrateur système qui maintient le système pendant 3 ou 5 ans quand le développeur est parti sur d’autres projets.
Il est évident que chez Debian, on fait énormément confiance aux développeurs. Il y a juste des paramètres qu’ils ne connaissent pas au début et qu’on va lui communiquer pour que l’application et le paquet Debian évoluent pour le mieux. Tout le monde est gagnant à ce qu’un programme s’exécute bien sur un système, projet amont et la distribution en question.
Ce processus d’adaptation du code source du projet amont à Debian n’est pas automatisable. Trop de paramètres entrent en jeu. Et qui dit intervention humaine dit erreur possible, inutile de se voiler la face. D’un autre côté dans l’extrême majorité des cas, tout se passe pour le mieux pour les deux parties. Les patchs crées par le responsable Debian sont bien souvent proposés au projet amont qui peut décider de les intégrer. L’univers du libre permet cette fructueuse collaboration. J’entretiens moi-même d’excellents rapports avec les projets amonts des paquets que je maintiens et suis à leur écoute autant que faire se peut.
Bonjour,
Je me permets de commenter cet article car j’ai l’impression qu’il soulève une question fondamentale sur le rôle du packageur. Il te parait peut-être normal qu’un packageur se permette de patcher le code du logiciel qu’il s’apprête à proposer; de mon côté cela a tendance à me faire sauter au plafond.
Je m’explique: Si le programme ne convient pas tel quel et nécessite qu’on lui applique des patches, alors le développeur devrait proposer ses patches “upstream” et attendre leur intégration dans le logiciel par les programmeurs. D’une part, ils pourront vérifier ce patch: une fois intégré, la responsabilité de tout bug lié à la modification de celui-là leur incombera et les épaules du packageur seront soulagées. D’autre part, si bug il y avait, ce bug sera alors corrigé pour tout le monde.
Si les leaders du projet refusent d’intégrer le patch ou bien sont trop lents à les accepter, alors deux solutions sont possibles:
– soit ne pas packager (et ainsi s’éviter la peine inutile de bosser avec des gens qui ne veulent pas jouer le jeu)
– soit forker le projet et packager le fork (et prendre responsabilité du code)
Je pense vraiment que ce sont les deux seules alternatives valables. On ne peut pas s’amuser à modifier du code sans en assumer la pleine responsabilité. Si on modifie du code, il faut s’assumer développeur. Ça permet deux choses:
1) Se protéger: si un problème se présente ça viendra du développeur et ça ne pourra pas être un problème de packaging.
2) Éviter d’engager la responsabilité des développeurs sans qu’ils le sachent: un patch non accepté qui est appliqué quand même, c’est du code qu’on ne peut pas déboguer puisque par définition il ne fait pas partie du code.
Voilà, c’est mon point de vue. C’est aussi une des raisons qui font que je suis sous archlinux et pas sous debian 😉
Christophe-Marie Duquesne: Comme l’indique mon billet, patcher les sources d’un projet amont est parfois inévitable. Deux exemples : le projet amont va chercher ses bibliothèques dans des répertoires que ne répondent pas à l’organisation interne de la distribution. Tu proposes bien sûr tes modifications au projet amont (en leur signalant que les chemins absolus dans le code c’est mal :)) mais en attendant, tu ne réalises pas le paquet ?
Un autre exemple tout bête, ce même programme avec des chemins absolus codés en dur inclut une fonctionnalité de mise à jour automatique qui se lance à chaque démarrage de l’application. Hors si on laisse cette fonctionnalité s’exécuter, elle va bien sûr rendre le programme inopérant. On ne fait rien ou on corrige ?
Ce qui est permis pour Arch ne l’est plus pour Debian depuis longtemps.Cette distribution gère 39000 paquets, sur une dizaine d’architectures différentes et deux noyaux différents (Linux et FreeBSD). Même FreeBSD adapte les sources des ses 21000 ports pour tourner sur sa plateforme.
Les admins font leur job et les développeurs font le leur. Croire qu’un programmeur est forcément un bon admin qui prend en compte forcément toutes les problématiques liées à l’administration système n’est pas crédible. Le code source des nouveaux projets que j’intègre à Debian me crie le contraire 🙂
Je suis tout à fait d’accord sur le point que les développeurs ne sont pas toujours (voire rarement) des packagers, cela dit, ils fournissent en général un makefile (ou cmake, etc…) suffisamment fourni en options pour permettre un empaquetage plus aisé et une intégration plus simple.
Évidemment, si le programme doit être patché pour fonctionner correctement, la question ne se pose pas, il faut patcher pour le moment, et faire remonter les remarques upstream afin de ❶ ne pas avoir à le refaire lors des mises à jour et ❷ faciliter le travail d’intégrations des autres distributions, qui ont des chances d’avoir le même problème.
Je me permets aussi de rebondir sur « Ce qui est permis pour Arch ne l’est plus pour Debian depuis longtemps. », que je trouve totalement vrai, même si je doute du sens initial que tu as voulu lui donner. Officiellement, Arch gère uniquement dans les 3000 paquets sur deux architectures presque similaires ; dans la réalité on approche des 27000 paquets, avec, à la louche, 2000 de non valides (on attend toujours un moment où le ménage sera fait dans le dépôt utilisateurs…).
Si arch peut se permettre de ne rien patcher, ou presque, je pense que c’est uniquement par son caractère de rolling release presque « bleeding edge », là où debian joue la carte des versions fixées de paquets (à part dans experimental), quitte à avoir plein de versions d’un même paquet cohabitant sur le système (je pense à python et python2.6 par exemple…) afin de conserver une compatibilité avec des versions dépassées de logiciels (et quitte à garder des logiciels qui ne fonctionnent plus ou mal dans les dépôts).
Tout ça pour dire que je pense qu’il ne faut pas jeter la pierre à un packager qui patche lorsque c’est nécessaire, mais que trop de patch tue l’intérêt du patch. ☺
Parfois les « packageurs » Debian font mal leur boulot http://lists.debian.org/debian-security-announce/2008/msg00152.html
Dire que FreeBSD adapte parfois les sources c’est vrai, mais généralement cela concerne les fichiers tels que configure, Makefile.in, wscript etc. Les fichiers de configuration. On peut « patcher » les sources quand on a besoin d’une compatibilité ascendante.
olivier: Comme je le dis dans le billet, patcher un programme n’est pas une opération qui peut être automatisée, trop de paramètres entrent en compte. Il s’agit donc d’une opération pendant laquelle une erreur humaine peut arriver.
Face aux nombres de patches générés par les développeurs Debian, ça n’est vraiment pas de chance que ce soit arrivé sur openssl avec les conséquences qu’on connaît. Mais le modèle de Debian est stable et le succès que rencontre cette distribution depuis 13 ans confirment la bonne tenue du modèle malgré un imposant passage à l’échelle du nombre des paquets et des architectures supportées dans le temps.
Pour moi c’est une histoire de répartition des responsabilités. De mon point de vue, dès le moment où l’on patche, on se doit de prendre pour soi l’entière responsabilité de tout bug qui pourrait se produire, puisqu’on propose une version différente de celle qui est développée. Même si c’est une bête histoire de chemins relatifs/absolus.
En ce sens, le genre de faille telles qu’on a pu voir avec openssl sous debian sont de mon point de vue entièrement à mettre sur le dos du packageur. D’ailleurs c’est bien une faille de packaging, puisque celle-ci ne s’est pas reproduite sur les distrib non basées sur le format .deb.
Si cette responsabilité est assumée, tant mieux…
Christophe-Marie Duquesne: Du moment où un développeur Debian décide de patcher le projet amont, il prend toute la responsabilité de son acte. Il suffisait de voir la réaction de Debian suite à l’erreur sur openssl. J’ai trouvé ça très bien de réagir aussi vite et efficacement sans fausse pudeur sur le fait que ça émanait uniquement d’eux.
“Croire qu’un programmeur est forcément un bon admin qui prend en compte forcément toutes les problématiques liées à l’administration système n’est pas crédible”
Et bien évidemment, le contraire ne pose pas vraiment de problème, n’est-ce pas ?
Le packageur Debian n’est pas “admin”, ni “développeur”, il est juste … packageur. Point barre.
En tout cas, il n’y aucune raison qu’un individu adoubé “Debian” soit plus omniscient qu’un autre. D’ailleurs ce n’est pas l’individu qui “porte” les compétences de packaging mais plutôt la mécanique (dpkg & apt & cie).
Il serait d’ailleurs plus raisonnable d’éviter l’usage abusif du terme “développeur” debian, qui ne veut pas dire grand chose en fait.
Aucune Importance: Détrompe-toi, les membres de Debian sont des développeurs. Ils écrivent tous les outils qui vont automatiser les différents services qui font vivre Debian : création des masters des distributions, packaging, assurance-qualité, maintien de l’infrastructure. D’où l’appelation développeur Debian. Le packaging n’est qu’une activité parmi d’autres. Sans cette activité de développement, Debian s’arrêterait rapidement.
Christophe-Marie : justement de ce que je peux voir coté utilisateur c’est entièrement assumé par Debian, à savoir qu’il est précisé que les rapports de bugs doivent d’abord être faits à Debian, et c’est seulement le mainteneur qui fera éventuellement suivre au développeur si c’est de son ressort.
Pour les quelques paquets dont je suis un peu le packaging de loin, tout est fait pour limiter au maximum les patchs. Les mainteneurs remontent quasiment systématiquement leurs besoins, et au pire appliquent le patch le temps que la version fournie dans Debian intègre le correctif en question.
Bref, moi j’aime, ne changez surtout pas ça 🙂