Comme je le disais, l'intérêt n'est pas que de gagner quelques Mio...
Le fait que les librairies restent (et en pratique, pas que les librairies, mais tout ce qui est dépendance... j'avais eu l'expérience de voir l'essentiel d'une appli de création de CD d'install Fedora rester malgré une désinstallation ; en fait, seul le "métapaquet" du groupe d'applis le permettant était désinstallé) peut en dire long sur ce qu'on fait de la machine.
Je ne connais pas l'état exact des dépendances pour kmldonkey sur d'autres distros (et je le cite uniquement à titre d'exemple), mais sous Debian, si on active les Recommends (ce dont je ne suis pas fan du tout), il fait venir mldonkey-server (ce que je trouve particulièrement idiot - mais c'est comme ça , heureusement, par défaut, il n'est pas lancé)... si les dépendances ne sont pas enlevées, en désinstallant kmldonkey, il reste mldonkey-server...
De même, si j'installe cryptkeeper, il me fait venir encfs comme dépendance...
Ce genre de choses, ça peut attirer la suspicion... et je n'ai pas envie de donner encore plus de raisons de me faire gratter mon laptop à la sortie de l'avion, juste parce qu'un jour, j'ai testé cryptkeeper ou kmldonkey.
C'est sans doute de la parano, mais je vois la non-désinstallation des dépendances comme une fuite d'informations privées... et je trouve qu'il y en a bien assez comme ça (je fais partie des gens qui adoreraient pouvoir activer un mode "je n'enregistre rien de privé" dans mon environnement de bureau : non ! Je refuse de stocker mes mots de passe, bookmarks, cache, mails et cie en local, sur mes stations à clickodrome - il y a bien assez de manières d'accéder à ça via un partage réseau sécurisé).
En outre, comme je le disais, si on laisse les dépendances s'accumuler, bonjour le bordel à l'autocomplétion (par exemple) dans /etc et /usr/share...
Sans parler de problèmes, fonctionnels ou sécuritaires, qui peuvent arriver quand on laisse les choses s'entasser... il me semble avoir déjà vu des applis supporter libgnutls et libssl en même temps, en se servant de l'une en priorité, quand les deux sont installées.
Si je veux n'en utiliser qu'une, parce qu'elle a tel ou tel avantage (genre, il me semble que gnutls ne supporte pas de gérer un répertoire de certificats, mais un seul certificat à la fois), ça peut causer un problème si ces libs sont présentes en même temps... au moins me faire perdre du temps, jusqu'à ce que je me rende compte de ce qui coince (autre exemple avec ces deux libs : les noms des méthodes de chiffrage ne sont pas les mêmes - me suis encore cassé les dents dessus ce weekend).
Il y a aussi qu'il est plus pratique de gérer ce qui est installé sur un parc de serveurs, quand la désinstallation des dépendances est déterministe.
En ce moment, je bidouille pas mal CFEngine, et j'apprécie de pouvoir spécifier clairement la liste de ce que je veux qui soit présent sur la machine : pour ce qui est des dépendances et des désinstallations, c'est transparent - je ne spécifie que les paquets que j'aurais installés manuellement... ainsi, si j'installe un truc juste pour voir, je sais que s'il n'est pas listé dans ce qui doit être présent, lui et tout ce qu'il aura fait venir sera nettoyé au prochain fetch de la configuration...
Par contre, si le système ne faisait aucune différence entre paquets demandés, et leurs dépendances, ce serait lourd... très lourd : je serais obligé de spécifier explicitement ce dont je ne veux pas, plutôt que de me contenter de dire ce que je veux (ou alors, inclure la liste des dépendances récursives dans la liste de ce que je veux, voire enlever la gestion des désinstallations de mes scripts... pfff... paye ta galère)...
Bref, gagner quelques Mio, en effet, m'en fous pas mal (et encore, il y a des cas particuliers - j'ai récemment testé de l'OpenVZ dans du Virtualbox, et j'ai eu des tas d'emmerdes parce que pas assez de secteurs dans les disques virtuels, par rapport aux quotas, même s'il y avait largement assez d'espace - j'avais installé plein de trucs, et je me demandais ce qui faisait que je ne pouvais me connecter en SSH dans le conteneur : en fait, la machine ne pouvait plus rien y écrire)... mais ce n'est pas pour ça que je veux une gestion rigoureuse des dépendances installées... ;)
Je sais que ça va contre les anciennes traditions... mais les traditions, ça évolue : et aujourd'hui, moult gestionnaires de paquets supportent ça (et même par défaut). Franchement, j'aimerais vraiment voir cette fonctionnalité supportée dans des distros comme CentOS, parce que, aujourd'hui, c'est peu ou prou tout ce qui m'empêche de les utiliser (comme je le disais, quand on a goûté à quelque chose d'aussi pratique, difficile de revenir en arrière).
Donc, si la seule raison est la tradition, qui demande de moins bonnes pratiques que ce qui se fait maintenant : pourquoi pas ? Que ce soit possible n'est censé empêcher personne de faire comme avant (au moins jusqu'à ce que ça devienne la nouvelle tradition)...
[^] # Re: Et sinon...
Posté par Aefron . En réponse à la dépêche RPM va enfin de l'avant avec la version 4.6. Évalué à 2.
Le fait que les librairies restent (et en pratique, pas que les librairies, mais tout ce qui est dépendance... j'avais eu l'expérience de voir l'essentiel d'une appli de création de CD d'install Fedora rester malgré une désinstallation ; en fait, seul le "métapaquet" du groupe d'applis le permettant était désinstallé) peut en dire long sur ce qu'on fait de la machine.
Je ne connais pas l'état exact des dépendances pour kmldonkey sur d'autres distros (et je le cite uniquement à titre d'exemple), mais sous Debian, si on active les Recommends (ce dont je ne suis pas fan du tout), il fait venir mldonkey-server (ce que je trouve particulièrement idiot - mais c'est comme ça , heureusement, par défaut, il n'est pas lancé)... si les dépendances ne sont pas enlevées, en désinstallant kmldonkey, il reste mldonkey-server...
De même, si j'installe cryptkeeper, il me fait venir encfs comme dépendance...
Ce genre de choses, ça peut attirer la suspicion... et je n'ai pas envie de donner encore plus de raisons de me faire gratter mon laptop à la sortie de l'avion, juste parce qu'un jour, j'ai testé cryptkeeper ou kmldonkey.
C'est sans doute de la parano, mais je vois la non-désinstallation des dépendances comme une fuite d'informations privées... et je trouve qu'il y en a bien assez comme ça (je fais partie des gens qui adoreraient pouvoir activer un mode "je n'enregistre rien de privé" dans mon environnement de bureau : non ! Je refuse de stocker mes mots de passe, bookmarks, cache, mails et cie en local, sur mes stations à clickodrome - il y a bien assez de manières d'accéder à ça via un partage réseau sécurisé).
En outre, comme je le disais, si on laisse les dépendances s'accumuler, bonjour le bordel à l'autocomplétion (par exemple) dans /etc et /usr/share...
Sans parler de problèmes, fonctionnels ou sécuritaires, qui peuvent arriver quand on laisse les choses s'entasser... il me semble avoir déjà vu des applis supporter libgnutls et libssl en même temps, en se servant de l'une en priorité, quand les deux sont installées.
Si je veux n'en utiliser qu'une, parce qu'elle a tel ou tel avantage (genre, il me semble que gnutls ne supporte pas de gérer un répertoire de certificats, mais un seul certificat à la fois), ça peut causer un problème si ces libs sont présentes en même temps... au moins me faire perdre du temps, jusqu'à ce que je me rende compte de ce qui coince (autre exemple avec ces deux libs : les noms des méthodes de chiffrage ne sont pas les mêmes - me suis encore cassé les dents dessus ce weekend).
Il y a aussi qu'il est plus pratique de gérer ce qui est installé sur un parc de serveurs, quand la désinstallation des dépendances est déterministe.
En ce moment, je bidouille pas mal CFEngine, et j'apprécie de pouvoir spécifier clairement la liste de ce que je veux qui soit présent sur la machine : pour ce qui est des dépendances et des désinstallations, c'est transparent - je ne spécifie que les paquets que j'aurais installés manuellement... ainsi, si j'installe un truc juste pour voir, je sais que s'il n'est pas listé dans ce qui doit être présent, lui et tout ce qu'il aura fait venir sera nettoyé au prochain fetch de la configuration...
Par contre, si le système ne faisait aucune différence entre paquets demandés, et leurs dépendances, ce serait lourd... très lourd : je serais obligé de spécifier explicitement ce dont je ne veux pas, plutôt que de me contenter de dire ce que je veux (ou alors, inclure la liste des dépendances récursives dans la liste de ce que je veux, voire enlever la gestion des désinstallations de mes scripts... pfff... paye ta galère)...
Bref, gagner quelques Mio, en effet, m'en fous pas mal (et encore, il y a des cas particuliers - j'ai récemment testé de l'OpenVZ dans du Virtualbox, et j'ai eu des tas d'emmerdes parce que pas assez de secteurs dans les disques virtuels, par rapport aux quotas, même s'il y avait largement assez d'espace - j'avais installé plein de trucs, et je me demandais ce qui faisait que je ne pouvais me connecter en SSH dans le conteneur : en fait, la machine ne pouvait plus rien y écrire)... mais ce n'est pas pour ça que je veux une gestion rigoureuse des dépendances installées... ;)
Je sais que ça va contre les anciennes traditions... mais les traditions, ça évolue : et aujourd'hui, moult gestionnaires de paquets supportent ça (et même par défaut). Franchement, j'aimerais vraiment voir cette fonctionnalité supportée dans des distros comme CentOS, parce que, aujourd'hui, c'est peu ou prou tout ce qui m'empêche de les utiliser (comme je le disais, quand on a goûté à quelque chose d'aussi pratique, difficile de revenir en arrière).
Donc, si la seule raison est la tradition, qui demande de moins bonnes pratiques que ce qui se fait maintenant : pourquoi pas ? Que ce soit possible n'est censé empêcher personne de faire comme avant (au moins jusqu'à ce que ça devienne la nouvelle tradition)...