Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Shell et commandes GNU Discussion :

Fonctionnement interne des outils de gestions de paquets


Sujet :

Shell et commandes GNU

  1. #1
    Membre éclairé
    Fonctionnement interne des outils de gestions de paquets
    Hello,

    Je cherche des info ou toute doc sur le fonctionnement interne (pas l'utilisation) des outils de gestions de paquets comme apt, emerge ou autres.
    C'est à dire en particulier la gestion des dépendances, la détection des bloquages, etc ...

    Thx

    ++
    Two beer or not two beer. (Shakesbeer)
    Question technique par MP => poubelle!

  2. #2
    Membre confirmé
    Bonjour,
    la commande emerge utilise des ebuilds. Il s'agit d'un fichier texte avec à l'interieur les éléments essenciels tel que : l'adresse du source, les USES flag utilisable et la liste des dépendances. La commande emmerge se '"acantone" à les lires et à scanner sa base pour vérifier que les dépendances sont satisfaites.

    Comme je n'ai jamais fait de rpm ni de paquet debian j'en dirai pas plus. Je sais pas si j'ai un peu fait avancé le sujet

  3. #3
    Membre éclairé
    Salut,

    malheureusement, non Je suis "gentooiste" aussi, donc, je connais le principe d'utilisation et de construction des ebuilds. Ce que je cherche, c'est de la doc sur la mécanique interne de portage, les algos utilisés, etc ...

    Mais merci d'avoir pris le temps de répondre.
    Two beer or not two beer. (Shakesbeer)
    Question technique par MP => poubelle!

  4. #4
    Membre éclairé
    Il s'agit majoritairement de travailler sur le graphe des dépendances.

    Pour installer un package, il faut que toutes ses dépendances soient résolues.
    Un parcours en profondeur du graphe, en partant du package a installer , et qui s'arrete aux niveaux des packages déja installés te donne donc la liste des packages a installer pour installer ledit logiciel.

    Pour la politique de suppresion, il s'agit encore d'utiliser le graphe des dépendances. On ne peut détruire un paquet dont dependent d'autres paquets. Il faut donc que la liste des paquets auquel il est necessaire soit vide. On peut aussi envisager de détruire tout le sous-abre partant de ce paquet ( la méthode de parcours n'a pas d'importance je dirai ). Une dernière option peut-etre de supprimer les paquets utilisés uniquement par ce paquet ( que l'on vient de détruire ). On regarde alors tous les paquets dont ledit paquet depend et on regarde si le nombre de paquet qui dependent de ce paquet est > 1 ( je pense que ca devient embrouillé mais avec un papier , un crayon, ca doit aller ).

    Pour la politique de mise à jour, c'est a peu pres pareil.

    Il y'a d'autres problèmatiques à resoudre : paquet qui change de nom, différentes versions d'un "meme" paquet qui peuvent compliquer la gestion du graphe mais basiquement, ca reste des problèmes de graphe assez basiques.

  5. #5
    Membre éclairé
    oui, le principe "sur papier" est relativement simple.
    J'ai déjà implémenter un système de gestion des dépendances, upgrade et downgrade. Il fonctionne, mais, je souhaite voir ce qu'utilisent des systèmes "pro", histoire d'amener un peu de pérennité (fonctionauxquelles je n'avais pas pensé par ex).
    Two beer or not two beer. (Shakesbeer)
    Question technique par MP => poubelle!