CUDF, ou la résolution de dépendances universelle

Posté par  (site web personnel, Mastodon) . Modéré par Xavier Teyssier.
16
19
mai
2010
Technologie
Lors du dernier FOSDEM, une conférence sur le sujet de la résolution des dépendances dans les distributions a été faite par Stefano Zacchiroli qui (rien à voir) est devenu DPL Debian depuis.

La plupart des distributions se basent sur un ensemble de paquets (contenant logiciels, bibliothèques, et autres) liés entre eux par différents types de dépendances. Les formats de paquets les plus répandus sont les fichiers deb (Debian et dérivées), et rpm (Red Hat et dérivées). Les outils dpkg et rpm permettent de manipuler les paquets en local. La couche du dessus, qui contient des outils comme apt et yum, permet la résolution des dépendances. L'utilisateur peut donc choisir les paquets qu'il souhaite installer, et les dépendances sont résolues afin que les paquets nécessaires soient installés et que les éventuels paquets en conflit soient supprimés. L'outil de résolution des dépendances a pour seul but de répondre aux besoins de l'utilisateur sans enfreindre les règles de dépendances et de conflits définies. Éventuellement, cet outil peut répondre qu'il n'existe aucune solution au problème posé...

Dans les faits, il existe différents solveurs de dépendances différents entre les distributions, et même au sein de chaque distribution. Dans la plupart cas, il n'existe pas de bonne raison à cet état de fait. Seuls certains domaines spécifiques (par exemple, l'embarqué) peuvent nécessiter un algorithme de résolution différent. Lors de sa conférence intitulée « Cross-distro dependency resolution: reusing solvers among distros », Stefano Zacchiroli, développeur Debian, présente le travail réalisé dans le but de créer un format standard de description des problèmes de résolution de dépendances. Ceci a pour but de pouvoir abstraire ces derniers en omettant les spécificités de chaque distribution (par exemple, transformer les différents niveaux de liens entre les paquets dans Debian : Depends/Recommends/Suggests/Conflicts/Replaces/etc. et la notion de paquets virtuels), et donc de pouvoir travailler sur des solveurs performants et éventuellement utilisés largement par les différentes distributions, en évitant la duplication du travail.

Plus de détails dans la suite de la dépêche

NdM : Merci à Adrien Cunin pour son journal à l'origine de la dépêche. Cette abstraction correspond au format CUDF, acronyme de Common Upgradability Description Format. Un fichier CUDF est un simple fichier texte basé sur la RFC 2822, listant des paquets (chacun ayant un certain nombre de propriétés), le tout organisé en 3 sections :
  • l'univers des paquets, c'est-à-dire la liste des paquets disponibles dans les dépôts ;
  • les paquets installés ;
  • la requête de l'utilisateur.
Un document contenant les spécifications complètes est disponible, mais pour commencer il est suffisant de lire le primer CUDF. Ce format est implémenté dans la libCUDF, également disponible sur le site du projet CUDF. Il existe un format spécifique pour Debian, Debian CUDF, qui abstrait moins de choses que le format CUDF, et qui trouve son utilité dans le travail d'uniformisation des solveurs au sein de la distribution Debian.

Enfin, l'équipe derrière CUDF souhaite collecter des données auprès des utilisateurs de systèmes de paquets afin de constituer une base de cas d'utilisation réels sur les problèmes de résolution de dépendances. De plus, une compétition sera organisée entre les différents algorithmes de résolution proposés.

Tout ce travail, même s'il peut sembler actuellement abstrait, pourrait permettre à terme d'améliorer les systèmes de paquets dans les distributions.

Aller plus loin

  • # Paquets universels ?

    Posté par  . Évalué à 4.

    Je me demandais : quitte à essayer de faire un outil qui soit universel, pourquoi ne pas essayer de changer le système de paquet lui-même ?
    J'avoue ne pas connaître leur fonctionnement et même si c'est possible en théorie, mais j'ai remarqué que certain trouvait que de devoir générer un paquet par distribution était dommageable pour la communauté en général.
    • [^] # Re: Paquets universels ?

      Posté par  . Évalué à 3.

      En théorie, le format de paquet "officiel" pour Linux est le Rpm_(red_hat), mais les discussions sur ce point semblent assez trollesque. L'utopie voudrait donc qu'un nouveau format de paquets, reprenant le meilleurs de tous les systèmes existants (flemme de ne serait-ce que penser à en faire une liste complète -_-" ), fasse son apparition et soit communément accepté par tout le monde et que toutes les distribution revoient les fondements de leur système pour l'adopter ...

      Ouai, utopie c'est peut-être bien le bon mot : génial mais irréaliste :(
      • [^] # Re: Paquets universels ?

        Posté par  (site web personnel) . Évalué à 3.

        En théorie, le format de paquet "officiel" pour Linux est le Rpm_(red_hat),

        Et ça sort d'où cette théorie ?
        • [^] # Re: Paquets universels ?

          Posté par  . Évalué à 9.

          Je pense qu'il fait référence à LSB (Linux Standard Base) qui a tenté une certaine homogénéisation mais avec un défaut suremment : celui de vouloir créer de la compatibilité binaire (ce qui, dit on, sert surtout aux logiciels propriétaires).
          • [^] # Re: Paquets universels ?

            Posté par  (site web personnel) . Évalué à 8.

            Et qui a juste créé une troisième version de format RPM moins riche que les deux autres.

            "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

      • [^] # Re: Paquets universels ?

        Posté par  (site web personnel) . Évalué à 5.

        > L'utopie voudrait donc qu'un nouveau format de paquets [...] fasse son apparition

        Et encore, ça ne résoudrait pas grand chose. On pense souvent que le problème vient du fait que le format DEB et le format RPM sont différents, mais quand on creuse on se rend compte que c'est faux. Exemple : je suis sur Fedora, je vais chercher sur rpmfind.net un paquet lambda qui correspond à mon application manquante. Il se trouve que le paquet vient de chez SuSE ou Mandriva, sur une version n-2, et donc forcément quand j'essaye de l'installer, je me fais jeter.
        Et pourtant, c'est bien un RPM.

        Le problème de compatibilité entre les paquets des distributions ne vient pas du format, mais du fait qu'ils sont compilés avec des bibliothèques différentes, pas forcément compatibles, avec des options différentes, etc.
        En fait, le problème vient du fait que les paquets viennent de distributions différentes.

        C'est là d'ailleurs le fond du problème : supposer que n'importe quel RPM peut s'installer sur n'importe quelle distribution basée sur RPM, c'est ignorer (voire nier) le travail de mise en cohérence fait par la distribution.

        Et au passage, les deux formats ne sont pas si différents l'un de l'autre. En gros une archive, des méta-données décrivant le paquet et ses dépendances, et des scripts à exécuter autour de l'installation et de la désinstallation du paquet. On fait tout un foin sur les incompatibilités entre ces deux formats, alors que le problème n'est pas là.

        Il y a selon moi quatre solutions au problème pour un distributeur de logiciel externe, si on exclut l'inclusion dans la distribution bien sûr :
        - la compilation statique
        - la fourniture, avec le programme, de ses bibliothèques dynamiques dans un dossier à part. C'est ce qui se fait le plus en ce moment (mozilla, jeux, etc.), mais c'est pas beaucoup mieux que la compilation statique
        - l'utilisation d'un format spécifique type autopackage ou klik (le truc de SuSE qui monte dynamiquement une image iso)
        - la distribution sous forme de source, avec peut-être un système pour créer automatiquement un package en local (type checkinstall)

        Aucune de ces solutions ne semble miraculeuse, sachant qu'elles sont toutes un pis-aller à l'inclusion dans la distribution.

        Autopackage n'a jamais vraiment décollé, c'est dommage je trouve. Des avis ?
        • [^] # Re: Paquets universels ?

          Posté par  (site web personnel) . Évalué à 2.

          Voilà un excellent résumé qui va au fond du problème (finalement assez simple) : l'usage des bibliothèques dynamiques.

          Problème qui est aussi celui des mises à jour.

          Cela dit, l'usage quasi exclusif des bibliothèques statiques me semble être une très mauvaise idée : lourdeur, bugs, bazar etc.

          Autopackage semblait être une bonne solution mais souffrait du manque d'intégration dans les distributions.

          Il me vient une idée :

          Les distributions pourraient peut-être proposer, pour les logiciels les plus couramment utilisés, le choix entre l'installation de la version "statique" et de la version "dynamique".

          "firefox" & "firefox-static", par exemple.

          Le logiciel d'installation "classique" proposerait le choix, le logiciel "simplifié" ferait le choix par défaut de la version statique. Ainsi le "end-user" pourrait bénéficier des maj de firefox rapidement.

          C'est ici qu'une normalisation telle que le CUDF serait intéressante, ainsi qu'un format standard (type rpm LSB) associé à l'obligation d'installer le logiciel dans le répertoire /opt (par exemple).

          Cela ne concernerait que les paquets "statiques". Les logiciels d'installation de paquet se contentant de suivre les recommandations pour ces paquets, tout en les séparant clairement des paquets "standards" (installation dans /opt). Ces logiciels s'occuperaient de la conversion automatique du rpm standard au format idoine.

          Tout cela a sans doute été déjà pensé, déjà contré, et déjà enterré ;)
          • [^] # Re: Paquets universels ?

            Posté par  . Évalué à 1.

            Et donc tu vourais charger dans ta RAM :
            -une version de Qt pour KDE (c'est un logiciel populaire)
            -une version de Qt pour Amarok (idem)
            -une version de Qt pour K3B (idem)
            -une version de Qt poru Skype (idem)
            -une version de GTK pour Firefox (idem)
            -une version de GTK pour Pigin (idem)
            ?
            Pas moi . Même si j'ai 2 Go de RAM, je préfère m'en servir pour compiler ou pour des jeux .
            • [^] # Re: Paquets universels ?

              Posté par  (site web personnel) . Évalué à 2.

              Moi non plus.

              Relisez-moi, je ne préconisais pas l'installation systématique d'applications avec bibliothèques statiques.

              Je me demandais si offrir le choix entre dynamique et statique, sachant que les applis "statiques" seraient plus régulièrement mises à jour et proposées par défaut dans l'interface d'installation "pour-les-nuls", ne seraient pas une solution relativement facile et rapide à mettre en place en ce qui concerne le principal reproche que l'on fait aux distros Linux :

              1) soit d'être "statique" (Debian stable/testing, ubuntu, fedora etc.) et de ne proposer que des applis vieilles.

              2) soit d'être "rolling-release" (Debian Sid, Gentoo, Arch etc.) mais d'être beaucoup moins solides.

              L'idée étant de proposer le choix entre libs statiques et dynamiques uniquement pour les applis populaires et dont il est bon d'avoir des maj fréquentes (openoffice, firefox etc.).

              Les applis "statiques" seraient installées dans "/opt" ce qui permettrait d'envisager une standardisation sur ce point et de mettre en place, enfin, des paquets cross-distro. Dès lors les trucs comme CUDF et LSB-rpm commenceraient à avoir un intérêt certain.
  • # Pas convaincu

    Posté par  (site web personnel) . Évalué à 2.

    Les problèmes qui me viennent à l'esprit :
    - les paquets n'ont pas les mêmes noms selon la distribution
    - les performances, à moins de stocker la base des paquets dans ce format il faut la transcoder à chaque opération
    - encore un nouveau format et donc un nouveau parseur, c'est pourtant pas le choix qui manque dans l'existant
    • [^] # Re: Pas convaincu

      Posté par  . Évalué à 8.

      Il ne faut pas confondre l'utilisation de ce travail et sa production.

      L'idée ici est simplement de proposer une abstraction sur les formats existants de telles sorte qu'on puisse produire un algorithme de résolution de dépendance générique qui puisse ensuite être utilisé par les différents formats.
      Il n'est pas question d'avoir un ensemble de paquet communs, une base de donnée commune ni un format commun.
      • [^] # Re: Pas convaincu

        Posté par  (site web personnel) . Évalué à 1.

        L'idée ici est simplement de proposer une abstraction

        L'abstraction c'est bien quand c'est justifié et utile, sinon ça ralentit pour rien.

        Il n'est pas question d'avoir […] un format commun.

        Bah si, un format de transaction commun à passer à un résolveur plus ou moins commun, ou alors je n'ai rien compris.
        • [^] # Re: Pas convaincu

          Posté par  (site web personnel) . Évalué à 10.

          Tu n'as rien compris.

          L'idée c'est que résoudre un problème de dépendances, c'est NP-complet (donc très très difficile, nécessitant beaucoup de puissance de calcul ou alors des optimisations astucieuses si tu veux obtenir un résultat avant la fin de l'Univers). Pour l'instant, chaque distribution, et même pire, chaque gestionnaire de paquet (il peut y en avoir plusieurs par distribution, par exemple apt-get et aptitude) fait son truc dans son coin. C'est complètement sous-optimal (duplication des efforts, pas de partage des connaissances, résultats issus de bidouillage plutôt que de recherche théorique avancée dans le domaine).

          La solution proposée, c'est un format qui soit capable de décrire un problème de dépendances. On se moque que les paquets s'appellent xyzpqrt ou gnome-vs-kde : chaque gestionnaire de paquet pourrait traduire sa liste de paquets dans ce format, puis passer le problème à un outil externe, unique, performant, indépendant du système de paquets utilisé. Le truc il fait sa tambouille magique et il répond, dans le même format commun standardisé : le gestionnaire de paquet n'a plus qu'à décoder la solution et la proposer à son utilisateur favori.

          Et ça marche déjà (sans être aussi efficace et automatisé que je le décris toutefois) : http://www.dicosmo.org/MyOpinions/index.php/2010/05/13/102-t(...)
          • [^] # Re: Pas convaincu

            Posté par  (site web personnel) . Évalué à -2.

            Étant donné que c'est exactement ce que j'ai dit j'ai du mal à voir ce que je n'avais pas compris selon toi.

            Quant au fait qu'on y gagnerait en performance je répète ce que je disais dans mon premier message, à moins de garder la base des paquets dans le format du résolveur il y aura un coup de transcodage à chaque opération.

            J'ai également un doute sur l'utilité de la chose pour une distribution en rolling-release et do it yourself style Arch Linux où il y a peu de conflits. Sortir l'attirail de recherche automatique de solution ne serait pas forcément bénéfique, quand bien même l'algorithme de résolution serait plus efficace.
            • [^] # Re: Pas convaincu

              Posté par  . Évalué à 6.

              Ouais enfin hier Arch n'arrivait pas à faire ma mise-à-jour, il a fallu que je vire CUPS d'abord. Ah oui, et en plus pacman a passé un temps fou (environ 15 minutes) avant de me dire qu'il n'arrivait pas à résoudre les dépendances. Et ce n'est pas la première fois que j'ai un problème de dépendance avec pacman.
              • [^] # Re: Pas convaincu

                Posté par  . Évalué à 2.

                Ah et pour en finir avec ma mésaventure d'hier : je fais la mise à jour d'openssl. Ok ça marche. Sauf qu'après, pacman est incapable d'installer quoi que ce soit. Il demandait la 0.9.8 alors que j'avais maintenant la 1.0.0.
              • [^] # Re: Pas convaincu

                Posté par  . Évalué à 2.

                Tu les fais tous les mois les mises à jour pour que tout casse comme ça ? Moi j'utilise Arch depuis quelque mois et je n'ai jamais eu de problème avec les mises à jour .
                • [^] # Re: Pas convaincu

                  Posté par  . Évalué à 2.

                  Oui, celle-ci ça faisait plus d'un mois, voire même deux ou trois.
            • [^] # Re: Pas convaincu

              Posté par  . Évalué à 4.

              Tu déconnes ? les distributions ou ça bouge tout le temps sont carrément sujettes à ce genre de problèmes, genre des paquets en dépendances qui sont pas mis à jour à la même vitesse, le problème de Di Cosmo du meta paquet gnome cassé ... ça arrive tout le temps.
  • # Ne pas oublier urpmi

    Posté par  (site web personnel) . Évalué à -1.

    Mandriva utilise urpmi dont l'une des nombreuses fonctions est de gérer les dépendances entre paquets. Urpmi est activement maintenu et les mises à jour de la distribution, qu'elles soient automatiques ou manuelles, fonctionnent parfaitement.

    Je pense que CUDF arrive un peu tard et a maintenant peu de chances d'être intégré à apt ou urmpi qui sont actuellement les gestionnaires de paquets les plus performants.
  • # Installation des paquets et des dépendances

    Posté par  (site web personnel) . Évalué à 9.

    Je me suis toujours demandé pourquoi tous les paquets (ceux vraiment souhaités et leurs dépendances) étaient téléchargés puis installés en un bloc.

    Je m'explique : on souhaite installer un ensemble de paquets. Ces paquets ont un ensemble de dépendances. Ces dépendances étant elles-même des paquets, elles peuvent avoir leurs propres dépendances, etc. Au final, on se retrouve avec des paquets stratifiés : les paquets dont toutes les dépendances sont présentes (ou qui n'en n'ont pas) permettent d'installer les paquets qui dépendent d'eux.

    Il en résulte qu'il est possible de commencer par récupérer localement une partie choisie des paquets voulus (appelons ça une vague), et de les installer pendant que la récupération des paquets dépendant des premiers commence. Cette approche a l'avantage de ne pas faire dormir le processeur pendant le téléchargement, et de ne pas négliger la bande passante pendant que le processeur (et autres périphériques) moulinent pour installer les paquets. Donc on gagne du temps, et pour peu que l'installation de chaque vague de paquets se déroule correctement, les dépendances sont respectées. Si l'installation d'une vague échoue, seuls les paquets dépendant des paquets de la vague seront impactés.

    A ma connaissance, aucun outil ne propose ça. Y a-t-il des pistes dans ce sens?
    • [^] # Re: Installation des paquets et des dépendances

      Posté par  (site web personnel) . Évalué à 2.

      Si j'ai bien compris ce que tu veux faire c'est télécharger et installer en parallèle, par « vague » de dépendances. Ça me semble être une bonne idée même si quand on télécharge on écrit aussi sur le disque. Une option pour faire passer les paquets par un dossier temporaire, par exemple /tmp, pourrait peut-être accélérer la chose en utilisant tmpfs.

      Je pense qu'une raison pour laquelle ça n'existe pas est que la parallélisation est souvent plus pénible à coder. Il est également plus difficile de rendre compte de l'avancement de travaux parallèle dans un terminal.
      • [^] # Re: Installation des paquets et des dépendances

        Posté par  (site web personnel) . Évalué à 1.

        La difficulté de parallélisation ne me semble pas être une bonne excuse : c'est certainement un effort à faire, mais il me semble que ça apporterait une plus-value. De plus, il est peut-être possible d'imaginer un système commun à tous les systèmes de paquets avec dépendances. On rejoint alors l'esprit de l'article. Enfin, je dis ça, mais il ne faudra pas compter sur moi pour le faire ^^

        Pour ce qui est de suivre l'évolution de l'installation, je ne vois pas le problème : on continue à avoir des paquets à installer, des paquets installés, et des paquets en cours d'installation. Selon mon approche, ce qui pourrait changer c'est que des paquets peuvent être téléchargés pendant que d'autres sont installés. Cette partie peut être plus difficile à représenter en console (pas avec des jauges, quoi). Mais au pire on peut toujours avec un pourcentage de paquets installés, et "oublier" de représenter le téléchargement des paquets qui se fait en arrière-plan.

        Le problème de l'utilisation du disque dur me semble plus complexe. Mais dans mon cas (qui n'est sûrement pas une généralité, mais qui touche encore pas mal de monde je pense), le goulot d'étranglement n'est pas tant au niveau de l'écriture sur disque que la bande passante : dans mon cas, je vois la barre de progression des téléchargements avancer à vitesse de tortue, puis l'installation proprement dite s'exécute en un éclair.

        Je me dis souvent que l'installation de la plupart des paquets déjà téléchargés aurait pu se faire 6-7 fois le temps que le téléchargement soit tout à fait terminé.
        • [^] # Re: Installation des paquets et des dépendances

          Posté par  (site web personnel) . Évalué à 5.

          Il me semble qu'il y a un autre problème, c'est quand tu perds ta connexion en cours de route. Avec un système actuel, l'installation ne commencera pas. Avec ta proposition, la moitié des dépendances sera déjà installée, il faudra donc prévoir un système de retour en arrière (downgrade des paquets upgradés), ce qui nécessite que le système de paquets le supporte (pour info, la Debian Policy n'impose pas qu'un paquet soit downgradable, même s'il est possible pour l'empaqueteur de prévoir le cas − c'est même conseillé).
          • [^] # Re: Installation des paquets et des dépendances

            Posté par  (site web personnel) . Évalué à 1.

            Si les anciennes versions des paquets sont encore en cache on peut revenir en arrière sans problème à condition d'attendre la fin des téléchargements pour commencer l'exécution des scripts ( post-installation, etc ) si ceux-ci effectuent des opérations irréversibles ( mise à jour de config par exemple ).

            Si les anciennes versions ne sont pas en cache on peut imaginer de créer ce cache de sauvegarde avant de commencer la mise à jour mais au final ça risque de ne pas valoir le coup, à part si la mise à jour concerne 200 paquets et qu'un seul n'est pas en cache.
        • [^] # Re: Installation des paquets et des dépendances

          Posté par  . Évalué à 1.

          dans mon cas, je vois la barre de progression des téléchargements avancer à vitesse de tortue, puis l'installation proprement dite s'exécute en un éclair.

          Et donc tu voudrais faire une partie de l'installation pendant le téléchargement, histoire d'améliorer les choses... Si tu arrivait à paralléliser complètement, alors le temps total de l'opération (tortue) serait le temps de téléchargement uniquement, puisque l'installation est plus rapide (éclair). Au final, tu ne gagneras presque rien, tu auras toujours une vitesse de tortue.

          Tu as dit toi-même que le goulot d'étranglement c'est la bande passante de téléchargement. Si tu veux vraiment améliorer les choses, c'est là qu'il faut intervenir, pas sur le traitement suivant qui ne prend qu'une partie négligeable du temps total.

          Je me dis souvent que l'installation de la plupart des paquets déjà téléchargés aurait pu se faire 6-7 fois le temps que le téléchargement soit tout à fait terminé.

          CQFD.
          • [^] # Re: Installation des paquets et des dépendances

            Posté par  (site web personnel) . Évalué à 1.

            Sauf que ce n'est pas toujours le cas. Par exemple chez moi, avec un téléchargement à 1,5 Mo/s et un ordi pas trop récent, le téléchargement est souvent plus rapide que le dépaquetage et configuration des paquets. En fait ça dépend beaucoup de la bande passante et de la vitesse de la machine, mais dans mon cas ce serait intéressant. Avec une faible bande passante et une machine lente, ça le serait encore plus. Reste le souci que j'ai soulevé plus haut (qui n'est pas insurmontable)…
    • [^] # Re: Installation des paquets et des dépendances

      Posté par  (site web personnel) . Évalué à 4.

      Bonjour,

      Ça existe, il y a déjà pas mal de monde qui y a pensé. Le gestionnaire de paquets, Setup, que je développe, en est au moins un qui fonctionne comme cela.

      Il télécharge les paquets et les installe en même temps, sachant qu'on peut également télécharger plusieurs paquets en même temps et en installer plusieurs en même temps.

      Pour copier des fichiers, pas besoin d'avoir les dépendances déjà installées. Le seul problème est qu'un paquet peut vouloir modifier une de ses dépendances (mais ça pue, par exemple, on n'écrit pas dans /etc/X11/xorg.conf, on ajoute un fichier dans /etc/X11/xorg.conf.d. Plus de problèmes).

      Pour cela, il y a les triggers, qui sont des scripts lancés séquentiellement une fois tous les paquets installés. Par contre, l'ordre des triggers les uns par rapport aux autres n'est pas assuré. Là, des modifications globales sont permises, comme un ldconfig, etc.

      Les scripts de postinst et preinst sont eux exécuté juste après l'installation du paquet, par un processus Bash lancé par le thread qui installe le paquet. Ce script ne peut toucher qu'au paquet en cours d'installation (envoi de communications, un système à la debconf mais en mieux intégré, configuration en fonction de l'ordinateur sur lequel le paquet est installé (architecture, paramètres réseau), etc).

      Et en effet, ça aide vraiment. Je bootstrap Logram en moins d'une minute, en installant build-essential (qui ramène logram-minimal-core). C'est un système qui ne démarre pas, mais qui contient Bash, les binutils, util-linux-ng, xz, tar, bzip2, less, sed, grep, etc.

      Une petite visite de mon site perso, en particulier cette page : http://logram-project.org/packages-4-1.html , te montrera ce que contient ce paquet. Le site en lui-même présente Setup. J'ai également des journaux qui en parlent ainsi qu'une dépêche.

      Voilà, j'ai assez fait ma pub.
      • [^] # Re: Installation des paquets et des dépendances

        Posté par  (site web personnel) . Évalué à 2.

        question conne : comment un programme va poser un fichier dans etc/X11/xorg.conf.d si X n'est pas installé (et que le répertoire n'existe pas) ?

        Ce que je veux dire par là, c'est que je ne comprend pas _du tout_ comment ton gestionnaire fonctionne s'il n'est pas capable d'installer les paquets dans l'ordre... (à moins de faire des tests ds des cas particuliers uniquement)
        • [^] # Re: Installation des paquets et des dépendances

          Posté par  (site web personnel) . Évalué à 2.

          J'utilise libarchive pour décompresser les archives, et il s'en fiche que xorg.conf.d n'existe pas, il le crée dans ce cas.

          En fait, j'ai prévu le machin pour fonctionner dans 98% des cas, et être très rapide. Les 2% des cas restant peuvent soit être contournés (/etc/nginx/conf.d à la place de /etc/nginx/nginx.conf, etc), soit on adapte le solveur.

          Par exemple, on sait qu'on va installer disons 2 paquets à la fois. Si le paquet nginx-mod-smtp pré-dépend de nginx, alors la liste des paquets installés (PackageList pour ceux qui lisent le code, ça se trouve sur Gitorious.org, projet "logram") va ordonner les paquets pour s'assurer que nginx sera au moins deux positions avant dans la liste par rapport à nginx-mod-smtp.

          Ainsi, ce dernier paquet sait que nginx est d'office installé, et peut fonctionner :) .
          • [^] # Re: Installation des paquets et des dépendances

            Posté par  (site web personnel) . Évalué à 3.

            Désolé, mais ça ressemble vraiment à de la petite tambouille tout ça... (je dis ça dans ton contexte de créer une distrib, une gestion de paquet, etc)

            je passe sur le 98%, c'est juste une mauvais solution à mon avis de raisonner comme ça pour ce genre de problème.

            Pour l'histoire des 2 paquets, comment tu fais si je demande d'installer nginx et nginx-mod-smtp sachant que toutes les autres dépendances sont ok ?

            Et surtout, pourquoi ne pas, simplement, installer les paquets dans l'ordre en permettant de paralléliser ce qui est possible, ie non mutuellement dépendant ?
            Alors c'est sur, c'est tout de suite beaucoup plus complexe, mais maintenant je commence à comprendre comment tu as pu écrire un gestionnaire de paquet si rapidement, c'est juste qu'il n'est pas encore réellement capable et propre.

            Dépendre de l'ordre de téléchargement pour installer est à mon avis assez mauvais et surtout pas beau du tout.

            (note : spa maichant hein, mais quitte à vouloir faire un truc et à balancer du code, autant le réfléchir et pas se faire trop avoir ...)
            • [^] # Re: Installation des paquets et des dépendances

              Posté par  (site web personnel) . Évalué à 2.

              En fait, il ne faut pas encore trop évaluer la qualité de Setup sur cette partie, qui n'est encore que minimale.

              Si tu veux installer nginx et nginx-mod-smtp, et qu'il n'y a pas d'autres paquets, il faut alors attendre que le premier soit fini, c'est à dire n'installer qu'un paquet à la fois. La partie du code qui ordonnera les paquets détectera ça et abaissera automatiquement les installations en parallèle (et pour ceux qui diraient «oui mais alors, ça ralenti également le reste de la liste», ben s'il y a d'autres paquets dans la liste, le problème ne se pose pas, donc on ne réduit rien du tout).

              Cette partie du code sera tout un optimiseur, qui remplira grosso-modo les fonctions suivantes :

              * S'arranger pour regrouper les paquets qui proviennent d'un CD ensemble, pour éviter les Insérez le CD 1, Insérez le CD 2, Insérez le CD 1, etc
              * Mélanger le plus possible les paquets des autres dépôts, pour pouvoir télécharger depuis autant de serveurs que possible si on DL beaucoup de paquets à la fois
              * Commencer la liste par N (où N est le nombre de DL en parallèle) gros paquets sur des dépôts différents, de préférence, puis placer tous ceux venant des CD. Ainsi, pendant le téléchargement, l'utilisateur peut s'amuser à rentrer les CD
              * Mettre les dépôts lents au début, les gros fichiers au début, pour éviter que le téléchargement se passe en 10 seconde puis qu'on attente 2h qu'un paquet de 300Mio soit DL depuis un serveur lent
              * Encore quelques détails pour les CD en prenant éventuellement en compte le temps de seek du CD (classer les paquets par ordre alphabétique, sachant que c'est dans cet ordre (plus ou moins) que mkisofs les place sur le CD, mais là je ne suis pas sûr).
              * Correction des problèmes cités plus haut : gérer les predepends.

              Le but de la manoeuvre est de tirer le maximum de tout ce qui tourne autour de l'installation. Maintenir la liste des paquets téléchargés mais pas encore installés la plus importante possible, pour que l'installation aille au maximum de ce que l'ordi permet. Les différents dépôts et mirroirs doivent être les plus utilisés possible, en même temps. Quand aux CD, c'est une question de confort que de ne pas avoir à constamment changer de CD. Et comme je compte à un moment où à un autre distribuer Logram sur CD (+DVD ou quelques CD pour le dépôt), il faut que ce soit bien géré.

              Ah oui, il faut aussi optimiser l'accès aux fichiers locaux. Ceux-là, comme ils sont quasiment instantanés, on les met entre les gros DL du début et les premiers CD. Ainsi, on peut commencer à installer très rapidement, pendant qu'on lit des CD et qu'on DL.

              Toute une science. Je sens que je vais passez des jours à ce que ça marche bien :) (mais quand ce sera fait, ce sera une des killer-features de Setup).
    • [^] # Re: Installation des paquets et des dépendances

      Posté par  (site web personnel) . Évalué à 2.

      Emerge fait ça sur Gentoo..
      C'est du prefetch, il dl le premier paquet, lance le build, et pendant ce temps continue à dl les autres paquets... Après c'est une distrib 'source', c'est peut-être moins facilement appliquable à une distrib binaire (mais j'en doute). J'ai trouvé l'option assez utile, car, de base, emerge télécharge le paquet, le construit, l'installe, puis fait la même chose pour le second paquet etc. etc. (contrairement aux 'autres' gestionnaires de paquets qui téléchargent tout, puis installent tout) Ainsi il est rapidement énervant de voir que le temps de la construction du paquet X qui vient de prendre 15minutes n'a même pas servi à pre-télécharger le paquet suivant qui fait 150Mo (genre open-office)
    • [^] # Re: Installation des paquets et des dépendances

      Posté par  . Évalué à 1.

      portage sous Gentoo le permet. Avec l'option paralell-fetch, il télécharge les paquets en arrière plan tandis qu'un autre compile.
    • [^] # Re: Installation des paquets et des dépendances

      Posté par  . Évalué à 2.

      Il y a aussi Sorcery, le gestionnaire de paquets de SourceMage Linux.
      Je pense que cette fonctionnalité a été développé dans Sorcery et dans Portage car le temps d'attente est centuplé par la nécessité de compiler les paquets.
  • # et packagekit

    Posté par  . Évalué à 5.

    Euh,

    Ca pourait pas être un prolongement de projet packagekit qui tends a uniformiser la couche d'au dessus.
  • # Pour rappel et article

    Posté par  (site web personnel) . Évalué à 5.

    Ces travaux découlent du projet Mancoosi [http://www.mancoosi.org/] auquel participe l'équipe PPS de l'Université Parsi VII dont font partie Stefano Zacchiroli et Roberto Di Cosmo [http://www.pps.jussieu.fr/].

    Sur le site de Mancoosi, on peut trouver pas mal d'articles de recherches sur la complexité de la gestion des dépendances logicielles.

    Je recommande particulièrement la lecture du papier "Strong Dependencies between Software Components" [http://www.mancoosi.org/papers/esem-2009.pdf] qui présente les dépendances des packages de la distribution Debian (avec plein de théorie des graphes de ands ;) ).
  • # Moi, j'ai la meilleure gestion des des dépendances au monde...

    Posté par  . Évalué à 2.

    ...j'utilise Slackware .

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.