Donc, à priori, même nombre de dépendances... sauf que debianutils, concrètement, je me demande ce que ça fait la, ce ne sont que des scripts shell. A vue de nez, c'est utilisé par l'installation, mais du coup, pourquoi ce n'est pas utilisé par whiptail? Je n'en sais rien. Qui plus est, je pense que c'est "récent", mais ma mémoire me trompe peut-être.
Honnêtement, ce n'est pas énorme, c'est juste "une" dépendance, mais si on prend sur un système standard, il est hyper probable que libtinfo6 et libncursesw6 soient déjà installés, puisque requis par d'autres outils fréquemment utilisés. C'est beaucoup moins le cas des outils slang.
Selon aptitude:
libtinfo6 est requis (je prend pas les pre-depends, la flemme) par 622 paquets
libncursesw6 par 176
libpopt0 par 95
libslang2 par 36
libtinfo6 est requis par bash, qui n'est pas optionnel sur debian. libncursesw6 par aptitude, alsa-utils, fdisk, powertop, procps, entres autres, qui sont des outils particulièrement courants.
Libpopt0 est requis par samba-libs, qui n'est installé pour aucune raison valable sur mes systèmes (non, vraiment, aucune valable: mpd et mpv peuvent supporter SBM, donc c'est actif dans debian, mais c'est tout. C'est d'ailleurs un truc qu'il faut que je fasse, me compiler mpd, mpv, sdl pour ne pas dépendre de ça, parce que ça tire pas mal de dépendances dont je n'ai pas l'usage, mais qui sont sûrement très utiles pour d'autres). libslang2 n'a même pas cette "chance" d'être requis par un composant "inutile" (dans mon cas d'usage).
Après, il est évident que ça ne change pas grand chose, concrètement on parle de 232Kio décompressés pour libpopt et 1670Kio décompressés pour libslang, de nos jours c'est négligeable (environ 2meg, une paille).
D'un point de vue accessibilité et i18n, whiptail gagne probablement compte tenu de la dépendance optionnelle (recommandation) à libfribidi (support des scripts qui s'écrivent de droite à gauche).
Malgré tout, il s'agit d'un élément que je prend en compte: j'essaie de garder les choses gérables, et multiplier les dépendances a faible valeur ajoutée pour mon usage n'est pas quelque chose qui m'aide a aller lire les changelog. Et puis ça m'amuse d'avoir un système entièrement fonctionnel tout en connaissant quasi par coeur la liste des paquets installés :) c'est une vieille manie que je tiens de l'époque ou j'utilisais windows et connaissais par coeur les processus et services qui tournaient sur ma machine.
Ca ne sert pas à grand chose (ça m'a bien permis de dégommer ou un deux malwares, mais franchement, ça reste peu pertinent) mais c'est comme ça :)
Le programme lui-même, plus petit,
Effectivement, et la différence est de taille: 72.7k pour whiptail, contre 1251 pour dialog (archives debian décompressées), dialog lui-même pesant ses 248K contre 27K pour whiptail.
La doc de dialog se limite aussi à une page de man, de mémoire, mais celle-ci est, toujours de mémoire, nettement plus claire que celle de whiptail. Mais je suis peut-être biaisé.
[^] # Re: dialog
Posté par freem . En réponse au journal choose, pour des scripts shells interactifs. Évalué à 3. Dernière modification le 29 décembre 2022 à 14:17.
dialog:
Pas de dépendances supplémentaires si on descend dans l'arbre (tout ça ne dépend que de libc6 et de libtinfo6).
whiptail:
Donc, à priori, même nombre de dépendances... sauf que debianutils, concrètement, je me demande ce que ça fait la, ce ne sont que des scripts shell. A vue de nez, c'est utilisé par l'installation, mais du coup, pourquoi ce n'est pas utilisé par whiptail? Je n'en sais rien. Qui plus est, je pense que c'est "récent", mais ma mémoire me trompe peut-être.
Honnêtement, ce n'est pas énorme, c'est juste "une" dépendance, mais si on prend sur un système standard, il est hyper probable que libtinfo6 et libncursesw6 soient déjà installés, puisque requis par d'autres outils fréquemment utilisés. C'est beaucoup moins le cas des outils slang.
Selon aptitude:
libtinfo6 est requis par bash, qui n'est pas optionnel sur debian. libncursesw6 par aptitude, alsa-utils, fdisk, powertop, procps, entres autres, qui sont des outils particulièrement courants.
Libpopt0 est requis par samba-libs, qui n'est installé pour aucune raison valable sur mes systèmes (non, vraiment, aucune valable: mpd et mpv peuvent supporter SBM, donc c'est actif dans debian, mais c'est tout. C'est d'ailleurs un truc qu'il faut que je fasse, me compiler mpd, mpv, sdl pour ne pas dépendre de ça, parce que ça tire pas mal de dépendances dont je n'ai pas l'usage, mais qui sont sûrement très utiles pour d'autres). libslang2 n'a même pas cette "chance" d'être requis par un composant "inutile" (dans mon cas d'usage).
Après, il est évident que ça ne change pas grand chose, concrètement on parle de 232Kio décompressés pour libpopt et 1670Kio décompressés pour libslang, de nos jours c'est négligeable (environ 2meg, une paille).
D'un point de vue accessibilité et i18n, whiptail gagne probablement compte tenu de la dépendance optionnelle (recommandation) à libfribidi (support des scripts qui s'écrivent de droite à gauche).
Malgré tout, il s'agit d'un élément que je prend en compte: j'essaie de garder les choses gérables, et multiplier les dépendances a faible valeur ajoutée pour mon usage n'est pas quelque chose qui m'aide a aller lire les changelog. Et puis ça m'amuse d'avoir un système entièrement fonctionnel tout en connaissant quasi par coeur la liste des paquets installés :) c'est une vieille manie que je tiens de l'époque ou j'utilisais windows et connaissais par coeur les processus et services qui tournaient sur ma machine.
Ca ne sert pas à grand chose (ça m'a bien permis de dégommer ou un deux malwares, mais franchement, ça reste peu pertinent) mais c'est comme ça :)
Effectivement, et la différence est de taille: 72.7k pour whiptail, contre 1251 pour dialog (archives debian décompressées), dialog lui-même pesant ses 248K contre 27K pour whiptail.
La doc de dialog se limite aussi à une page de man, de mémoire, mais celle-ci est, toujours de mémoire, nettement plus claire que celle de whiptail. Mais je suis peut-être biaisé.