Malgré ma bonne volonté, je n’arrive pas à maintenir un rythme très régulier pour animer mon blog. Il faut dire que rédiger un bon article (c’est-à-dire avec du contenu intéressant, et avec une relecture pour éliminer la majorité des fautes d’orthographe et de grammaire) cela prend beaucoup de temps, et que le temps je n’en ai pas beaucoup à revendre.
En effet, depuis quelques temps je me suis mis à contribuer à dpkg. J’ai commencé avec un projet plutôt important, à savoir l’amélioration de dpkg-shlibdeps pour qu’il génère des dépendances minimales en fonction des symboles des bibliothèques utilisés par chaque programme. Tout au long, j’ai maintenu à jour une page du wiki avec les détails et l’avancement:
http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps.
Comme le développement était assez important, il a eu lieu sur une branche dédiée qui vient juste d’être intégrée dans la branche master (autrement dit, le résultat sera dans la prochaine version de dpkg, c’est-à-dire la version 1.14.8).
Ce projet représente à mon avis une avancée très importante car si les bibliothèques les plus importantes emploient ce mécanisme rapidement, la majorité des paquets auront des dépendances moins strictes et il sera beaucoup plus souvent possible d’installer un paquet de unstable dans stable sans avoir besoin de le recompiler. Autrement dit, il y aura moins de rétro-portages (« backports ») à compiler et il sera plus facile d’installer la dernière version d’une application donnée.
Ce premier projet étant terminé, je me suis attaqué à un plus petit problème mais qui est intéressant tout de même. Jusqu’à présent, dpkg-gencontrol se contentait de substituer les variables dans les dépendances et d’écrire le résultat bêtement dans le champ correspondant.
Parfois le jeu des substitutions introduit des dépendances en double (parfois plus ou moins stricte). Comme lintian se plaint de ces problèmes, cela a conduit de nombreux mainteneurs à supprimer les variables et à mettre en dur les dépendances souhaitées. Maintenant, cela n’est plus nécessaire. En outre, les dépendances sont optimisées de telle sorte que si une dépendance dans le champ Pre-Depends implique une dépendance du champ Depends, cette dernière est supprimée (il en va de même pour les dépendances plus faibles listées dans Recommends puis Suggests). Je viens de soumettre une série de patchs pour inclure toutes ces fonctionnalités.
Je ne sais pas encore quel sera mon prochain projet, mais les récentes discussions sur un nouveau format de paquet source m’interpellent et peut-être vais-je essayer d’implémenter quelque chose qui combine le support du format wig&pen et les avancées apportées par les VCS distribués.
Ces différents développements concernent le paquet dpkg-dev qui contient essentiellement du perl. Ceux qui ne maîtrisent pas le C et qui n’osaient pas s’approcher de dpkg à cause de cela peuvent retourner leur veste et nous rejoindre sur #debian-dpkg sur irc.debian.org et la liste de diffusion debian-dpkg.
Enfin, http://wiki.debian.org/Teams/Dpkg contient des informations intéressantes pour qui veut débuter sur ce projet.
Je voudrais te féliciter pour ce travail. C’est une idée que j’avais eu il y a assez longtemps mais je n’avais pas à l’époque les connaissances techniques pour le faire… Et quand j’ai commencé à vaguement savoir comment faire, j’étais sur autre chose… En tout cas, un coup de chapeau bien mérité à toi et à ceux qui t’ont aidé !
Un inverseur de dépendances ne serait pas du luxe. (Quelque chose qui transforme foo (>= x.y) en foo (= x.y), mais qu’on ne met qu’en Recommends:, et donc, il faudrait un Conflicts:)
(Pffff, il faut escaper les < à la main)
Un inverseur de dépendances ne serait pas du luxe. (Quelque chose qui transforme foo (>= x.y) en foo (< x.y), en ajoutant tous les cas amusant que ça peut donner). ça pourrait servir à calculer des Conflicts: à partir des shlibs, par exemple. (le cas typique serait pour un package qui contient des modules pour lesquels on a une dépendance sur libfoo (>= x.y), mais qu’on ne met qu’en Recommends:, et donc, il faudrait un Conflicts:)
Article intéressant, donc plusieurs commentaires :
* en effet, écrire un bon article en faisant attention à tout ce que tu évoques prend du temps… trop de temps, je suis d’accord et mon blog dit pareil 🙂
* les modifs sur dpkg-shlibdeps (que je découvre soit dit en passant) me semble super, mais plusieurs questions me viennent :
– ce soft est-il utilisé lors de toute génération de paquet ? (j’ai plutôt l’impression qu’il demande un travail supplémentaire par les mainteneurs)
– ce qui implique : cela va-t-il rapidement se répercuter sur testing, de façon à pouvoir les installer en effet sur etch ? (problème de rdesktop par exemple évoqué dans le wiki debian)
J’espère ne pas dire de conneries…
ps : il semble que mon commentaire ne soit pas passé la première fois, le revoici donc
glandium, tu pourrais commencer par soumettre un bug wishlist explicant tes besoins 🙂
Mais je n’avais jamais pensé à cette problématique et elle me semble à limite tiré par les cheveux, en effet si on accepte que certaines des fonctionnalités soient cassées parce qu’on met les dépendances associées en Recommends pourquoi devrait-on refuser que cette même fonctionnalité soit cassée du fait de la présence d’une version trop ancienne ?
er:k, dpkg-shlibdeps est utilisé à chaque fois qu’il y a un binaire ELF dans le paquet Debian. Donc il concerne un très grand nombre de paquets… en revanche on ne profitera de dépendances optimisées que si les paquets des bibliothèques fournissent les fichiers « symbols » nécessaires et à ce jour il n’y a aucun paquet qui fournit ces fichiers (normal, l’outil pour les générer — dpkg-gensymbols — arrivera dans unstable avec dpkg 1.14.8 aussi).
Donc cela va prendre un certain temps avant que l’impact soit significatif.
buxy: en général dans ce cas, la fonctionnalité est désactivée, pas cassée. Par contre, sans le conflit, elle risque de l’être, si la bonne version de la librairie n’est pas installée.