Les slots règlent le problème sur le court terme, en faisant que si on installe gtk+2, ça ne prend pas la place de gtk+1, un peu comme s'il s'agissait de 2 logiciels différents.
Mais au sein d'un slot, le problème se repose, et on ne peut pas considérer chaque version d'un logiciel comme un nouveau slot. D'autant que dans l'esprit, on démarre un nouveau slot quand l'API change, pas quand l'ABI change, puisqu'il s'agit d'une distribution source.
De toutes façons, on voit réguliérement sur les forums des cas qui ont échappé à ce système de slot, et où le reverse depending aurait évité tout problème.
Une autre utilité du «reverse depending», c'est si on veut inclure un binaire au sein d'une installation gentoo : si je met à jours une librairie (1), on détecte que notre binaire (qu'on ne peut pas recompiler) a toujours besoin de l'ancienne version, et au lieu de virer l'ancienne version pour la nouvelle, on garde les deux.
Le «reverse depending» est aussi essentiel si on veut migrer progressivement vers une nouvelle version de compilateur.
De toutes façons, pour moi, le reverse depending est une fonctionnalité de base, et je m'inquiéte de voir l'inintérêt de l'équipe de dvp pour cette fonctionnalité. Vous imaginez, vous, faire un urpme gtk qui ne vous dit pas que ça va casser votre gimp et votre gnome ? Moi non plus.
(1)je prends toujours l'exemple d'une librairie, cela peut paraître réducteur, mais bien garder à l'esprit que la plupart du temps, ce n'est pas l'utilisateur qui demande à installer une nouvelle version d'une librairie (sauf en cas de mise à jour), mais qu'il s'agit d'une dépendance d'un logiciel qu'il installe.
[^] # Re: Gentoo/....
Posté par JSL . En réponse à la dépêche Gentoo est bientôt disponible pour MacOS X. Évalué à 1.