c'est à toi de savoir si en retirant X ou Y ça cassera tout ton système
Le cas que tu cites, il est très facile à éviter. D'une part il y'a des outils pour ça, qui savent vérifier les dépendances inverses (qpkg, equery, etc.) et qui permettent de contrôler si un package est ou non nécéssaire à la bonne marche du système, donc l'utilisateur qui sait se servir d'une gentoo ne tombe pas dans ce genre de panneaux. De plus, le plus gros des désinstallations se fait par nettoyage, pas par suppression explicite (encore heureux tu me diras) : tu demandes de supprimer une application de ton world, puis tu fait un "depclean" pour supprimer aussi ses éventuelles anciennes dépendances qui ne seraient plus nécéssaires à aucun autre package.
Enfin bref, tu peux le croire ou pas, mais vraiment les désinstallations explicites qui cassent le systèmes ou d'autres paquets c'est juste des erreurs de débutants. (Après, on peut aussi considérer qu'il devrait y avoir des garde-fous systématiques plutôt que des bonnes pratiques à connaitre, ça se défend, c'est une autre approche).
Mais là où l'absence de gestion des dépendances inverses par "emerge" lui même pose problème, c'est dans des cas de ce genre là :
- tu as d'installé pkgA qui dépend de libfoo en version 1.0*
- tu veux installer pkgB qui dépend de libfoo 0.9*
- libfoo n'est pas packagé de façon à ce que la 1.0 et la 0.9 puissent cohabiter
=> "emerge pkgB" va passer par une installation d'une version 0.9.x de libfoo, et donc la désinstallation de la 1.0.y. Il casse au passage pkgA.
En pratique, ce genre de cas sont prévenus à la main par les packageurs (par exemple ils vont marquer pkgA et pkgB comme mutuellement exclusifs puisqu'ils ne peuvent pas cohabiter), mais encore faut-il détecter le danger (pas évident pour le mainteneur responsable de pkgA et qui n'a pas forcement pkgB sur son système), et du coup ça n'est souvent fait qu'une fois qu'un utilisateur des versions instables est tombé dedans. Là, une gestion intégrée des dépendances inverses serait biensûr la seule solution vraiment universelle.
C'est bien, ça marche, il y a des possibilités intéressantes, mais il n'y a pas de quoi refouler apt/urpmi et yum, vraiment pas.
Perso, en plus de deux ans d'utilisation de la branche testing de gentoo, j'ai vu eu une fois un problème attribuable à l'absence de gestion des dépendances inverses (un dowgrade de xvid qui cassait mon xawdecode). Je considère que c'est vraiment très négligeable comparé aux avantages spécifiques à Portage, mais ça n'est biensûr que mon avis.
[^] # Re: et les ports ?
Posté par tgl . En réponse à la dépêche Sortie de Gentoo MacOS. Évalué à 4.
Le cas que tu cites, il est très facile à éviter. D'une part il y'a des outils pour ça, qui savent vérifier les dépendances inverses (qpkg, equery, etc.) et qui permettent de contrôler si un package est ou non nécéssaire à la bonne marche du système, donc l'utilisateur qui sait se servir d'une gentoo ne tombe pas dans ce genre de panneaux. De plus, le plus gros des désinstallations se fait par nettoyage, pas par suppression explicite (encore heureux tu me diras) : tu demandes de supprimer une application de ton world, puis tu fait un "depclean" pour supprimer aussi ses éventuelles anciennes dépendances qui ne seraient plus nécéssaires à aucun autre package.
Enfin bref, tu peux le croire ou pas, mais vraiment les désinstallations explicites qui cassent le systèmes ou d'autres paquets c'est juste des erreurs de débutants. (Après, on peut aussi considérer qu'il devrait y avoir des garde-fous systématiques plutôt que des bonnes pratiques à connaitre, ça se défend, c'est une autre approche).
Mais là où l'absence de gestion des dépendances inverses par "emerge" lui même pose problème, c'est dans des cas de ce genre là :
- tu as d'installé pkgA qui dépend de libfoo en version 1.0*
- tu veux installer pkgB qui dépend de libfoo 0.9*
- libfoo n'est pas packagé de façon à ce que la 1.0 et la 0.9 puissent cohabiter
=> "emerge pkgB" va passer par une installation d'une version 0.9.x de libfoo, et donc la désinstallation de la 1.0.y. Il casse au passage pkgA.
En pratique, ce genre de cas sont prévenus à la main par les packageurs (par exemple ils vont marquer pkgA et pkgB comme mutuellement exclusifs puisqu'ils ne peuvent pas cohabiter), mais encore faut-il détecter le danger (pas évident pour le mainteneur responsable de pkgA et qui n'a pas forcement pkgB sur son système), et du coup ça n'est souvent fait qu'une fois qu'un utilisateur des versions instables est tombé dedans. Là, une gestion intégrée des dépendances inverses serait biensûr la seule solution vraiment universelle.
C'est bien, ça marche, il y a des possibilités intéressantes, mais il n'y a pas de quoi refouler apt/urpmi et yum, vraiment pas.
Perso, en plus de deux ans d'utilisation de la branche testing de gentoo, j'ai vu eu une fois un problème attribuable à l'absence de gestion des dépendances inverses (un dowgrade de xvid qui cassait mon xawdecode). Je considère que c'est vraiment très négligeable comparé aux avantages spécifiques à Portage, mais ça n'est biensûr que mon avis.