Journal utd : lancer une commande sans installer son paquet (Debian et dérivés)

Posté par Mathos6 le 18 octobre 2026 à 00:10. Licence CC By‑SA.

Étiquettes :

-22

oct.

2026

Bonjour à toutes et à tous,

Il m'arrive d'avoir besoin d'un outil une seule fois : un figlet pour une bannière, un nmap pour un scan ponctuel, une conversion avec ffmpeg. Je n'aime pas laisser sur ma machine des paquets dont je ne me resservirai pas, avec leurs dépendances. J'ai donc écrit utd (« Use Then Delete »), en Go, sous licence MIT.

Je précise que j’ai commencé par un prototype en bash et fait mes recherches avant de choisir Go. La réécriture a ensuite été faite en grande partie avec l’aide d’une IA, que j’ai guidée et dont j’ai testé le résultat. Elle a notamment ajouté search et --dry-run.

Démo de utd

Principe

utd lance une commande qui n'est pas installée :
utd figlet hello utd --delete=now nmap -p 22,80 192.168.1.11. Si la commande est déjà dans le PATH, il la lance simplement.
2. Sinon, il cherche le paquet qui la fournit.
3. Il demande à apt quelles dépendances manquent, puis télécharge les .deb avec apt-get download.
4. Il les extrait avec dpkg-deb -x dans /tmp/utd, sans toucher à /usr.
5. Il lance le programme depuis cet arbre privé. Si bubblewrap est présent, les paquets sont superposés au système en lecture seule, pour que les chemins codés en dur (/usr/share/figlet, par exemple) fonctionnent.

Pas d'apt install, pas de root. Tout disparaît au redémarrage, ou tout de suite avec --delete=now.

La partie délicate : retrouver le paquet

Le nom de la commande n'est pas toujours celui du paquet : dig est dans bind9-dnsutils, bat installe batcat, nc passe par le système d'alternatives. utd essaie plusieurs sources dans l'ordre (table d'alias intégrée, paquet de même nom, index Contents d'apt, base de command-not-found, apt-file, apt-cache search). Il vérifie chaque candidat en cherchant le binaire dans le paquet avant de l'exécuter. utd search <commande> montre le résultat sans rien lancer.

Limites

Debian et dérivés uniquement pour l'instant (le code est écrit autour d'une interface PackageManager, donc d'autres gestionnaires sont envisageables).
Les outils qui exigent root, des capacités ou des modules noyau (tcpdump, par exemple) ne marcheront pas depuis un arbre temporaire.
Ce n'est pas une sandbox de sécurité : la commande tourne avec tes droits, voit tes fichiers et le réseau.

Et `nix run` ou Distrobox ?

Ils font mieux sur la robustesse, la reproductibilité et l'isolation, et ils marchent hors de Debian. utd vise un cas plus étroit : sur une machine Debian, avoir une commande une fois, sans installer de gestionnaire ni de moteur de conteneurs, et avec un nettoyage automatique.

Installation

Un binaire statique (amd64 et arm64) est disponible dans les releases, avec les sommes SHA-256. Sinon : make build avec Go 1.24 ou plus.

Le dépôt : https://github.com/Mathos6/utd

C'est une version 0.1, et j'aimerais surtout des retours sur les cas où la résolution de commande échoue ou tombe sur le mauvais paquet, sur la gestion du dossier temporaire, et sur ce qui vous semblerait utile à ajouter. Merci d'avance !

# Peut-être plus simple ?

Posté par Dafyd le 18 octobre 2026 à 00:24. Évalué à 10 (+14/-2).
Peut-être plus simple ?

Voici "once", à rendre exécutable et à placer dans le PATH.
```
#!/bin/bash                                                                     

set -e                                                                          

[ "$1" != "" ] && {                                                             
    (which $1 &> /dev/null || brew install $1) && $* ; brew remove $1           
}
```
Et garanti sans IA. Remplacer brew par votre package manager.
Répondre
- [^] # Re: Peut-être plus simple ?
  
  Posté par abriotde (site web personnel, Mastodon) le 18 octobre 2026 à 08:24. Évalué à -10 (+1/-20).
  
  C'est justement ça que l'on ne veut pas : tu installé mais delete jamais. Certes c'est simple, mais personne n'a besoin de ça. On est pas assez stupide pour ne pas savoir qu'il faut installer ce qui n'est pas installé.
  
  Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
  
  Répondre
  - [^] # Re: Peut-être plus simple ?
    
    Posté par Dafyd le 18 octobre 2026 à 09:12. Évalué à 9 (+10/-2).
    
    Je m’insurge, mon script désinstalle bien la commande à la fin ! Brew remove.
    
    Répondre
    - [^] # Re: Peut-être plus simple ?
      
      Posté par cg le 18 octobre 2026 à 18:36. Évalué à 2 (+1/-1).
      
      Si ça installe des dépendances, elles ne seront pas supprimées avec un apt remove ou apt purge. Ce petit script once est moins propre que le utd présenté.
      
      Répondre
      - [^] # Re: Peut-être plus simple ?
        
        Posté par Dafyd le 18 octobre 2026 à 18:54. Évalué à 7 (+6/-0).
        
        Il se trouve que brew remove supprime par défaut les dépendances qui ne sont plus utiles. Avec apt il faudrait faire un autoremove —-purge.
        
        Répondre
        
        [^] # Re: Peut-être plus simple ?
        
        Posté par Voltairine le 19 octobre 2026 à 08:48. Évalué à 3 (+3/-2).
        
        Nettoyage complet :
        
        apt autopurge apt purge ~c apt autoclean
        
        Répondre
        
        [^] # Re: Peut-être plus simple ?
        
        Posté par moi1392 le 19 octobre 2026 à 10:06. Évalué à 5 (+4/-1). Dernière modification le 19 octobre 2026 à 10:07.
        
        J'ai peut-être raté un truc dans la discussion, mais cela fait bien longtemps que la commande apt remove supprime tous les paquets qui ont été installés par dépendance seulement et qui n'ont plus de dépendences après suppression du paquet à retirer du système.
        
        Donc si apt install xxx installe le paquet yyy, apt remove xxx supprimera également le paquet yyy.
        
        Si apt install xxx installe par dépendance yyy, et si par la suite un apt install zzz dépend également de yyy.
        Après avoir demandé la suppression de xxx et zzz, et ce dans n'importe quel ordre, la seconde suppression supprimera au passage le paquet yyy.
        
        Répondre
        
        [^] # Re: Peut-être plus simple ?
        
        Posté par cg le 19 octobre 2026 à 10:42. Évalué à 2 (+1/-1).
        
        Je n'ai pas ce comportement. C'est un réglage spécial ? Ça me semble aller à l'encontre de l'approche conservatrice de apt/dpkg, qui font le minimum par défaut.
        
        Répondre
        
        [^] # Re: Peut-être plus simple ?
        
        Posté par moi1392 le 23 octobre 2026 à 13:42. Évalué à 4 (+2/-0).
        
        J'ai pas l'impresison, chez moi :
        
        apt remove paraview ... SUPPRESSION : paraview python3-paraview
        
        Répondre
        
        [^] # Re: Peut-être plus simple ?
        
        Posté par Voltairine le 19 octobre 2026 à 12:54. Évalué à 2 (+2/-2).
        
        Non. Extraits de man apt-get :
        
        remove
        La commande remove est identique à la commande install, les paquets étant alors supprimés et non installés. Veuillez noter que la suppression d'un paquet en laisse les fichiers de configuration sur le système. Quand un signe plus est accolé (sans espace intermédiaire) au nom du paquet, le paquet est installé au lieu d'être supprimé.
        
        autoremove (et l'alias auto-remove depuis la version 1.1)
        Avec la commande autoremove, apt-get supprime les paquets installés dans le but de satisfaire les dépendances d'autres paquets et qui ne sont plus nécessaires.
        
        autopurge
        Identique à autoremove, mais autopurge supprime aussi les fichiers de configuration. C'est un raccourci pour autoremove --purge.
        
        Je te laisse lire les descriptions des autres options.
        
        Répondre
        
        [^] # Re: Peut-être plus simple ?
        
        Posté par cg le 19 octobre 2026 à 14:34. Évalué à 2 (+1/-1).
        
        la commande apt remove supprime tous les paquets qui ont été installés par dépendance seulement et qui n'ont plus de dépendances
        
        Je répondais pour apt remove. Tu voulais dire apt autoremove peut-être ?
        
        À ma connaissance, la version apt autoremove paquet n'existe pas. Par contre, il existe apt remove --autoremove paquet :
        
        --autoremove: If the command is either install or remove, then this option acts like running the autoremove command, removing unused dependency packages.
        Configuration Item: APT::Get::AutomaticRemove.
        
        On peut donc en faire le comportement par défaut sur une machine, mais ça n'est pas le comportement par défaut de la commande "apt-get remove".
        
        Ou alors je n'ai pas compris le sujet ?
        
        Répondre
        
        [^] # Re: Peut-être plus simple ?
        
        Posté par Voltairine le 19 octobre 2026 à 15:03. Évalué à 3 (+2/-1). Dernière modification le 19 octobre 2026 à 15:04.
        
        Et moi je répondais @moi1392 qui se trompe sur le fonctionnement de l'option remove ;-)
        
        Par contre toi tu as raison : remove par défaut ne supprime pas les paquets inutilisés installés comme dépendance du paquet à supprimer. Mais l'option autoremove existe bien, j'ai même cité le passage de la page de man la concernant…
        
        Au passage je serais curieuse de savoir pourquoi mon commentaire avec les trois commandes de nettoyage complet à reçu des notes négatives.
        
        Répondre
        
        [^] # Re: Peut-être plus simple ?
        
        Posté par cg le 19 octobre 2026 à 19:18. Évalué à 1 (+0/-1).
        
        oh, mon mauvais !
        
        pour les moinsages, je ne sais pas, c'est pas moi !
        
        Répondre
        
        [^] # Re: Peut-être plus simple ?
        
        Posté par moi1392 le 23 octobre 2026 à 13:49. Évalué à 2 (+0/-0).
        
        j'ai répondu à cg plus haut, chez moi apt à bien le comportement que j'ai décrit. Saaauuuf…. que je viens de refaire le test avec supertuxkart, et là ça ne marche pas :
        
        apt install supertuxkart
        
        m'installe en plus libangelscript2.38.0 libmbedcrypto16 libmcpp0 libshaderc1 libsquish0 supertuxkart-data
        
        et quand j'ai tenté de le supprimer, il ne supprime QUE le paquet supertuxkart
        
        Je me demande s'il n'y a pas eu une option qui a été activée par défaut à un moment puis retirée.
        Sinon je ne m'explique pas le comportement de paraview sur ma machine, et je suis vraiment sur d'avoir lu ce changelog il y a longtemps et d'avoir immédiatement fait le test.
        
        Répondre
        
        [^] # Re: Peut-être plus simple ?
        
        Posté par Voltairine le 23 octobre 2026 à 16:47. Évalué à 2 (+0/-0).
        
        C'est le comportement normal :
        
        sudo apt remove supertuxkart [sudo] Mot de passe de ally : Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires : libangelscript2.38.0 libboost-thread1.90.0 libmbedcrypto16 libopenjph0.28 libsquish0 supertuxkart-data libboost-iostreams1.90.0 libixml11t64 libmcpp0 libshaderc1 libupnp17t64 Veuillez utiliser « sudo apt autoremove » pour les supprimer. SUPPRESSION : supertuxkart Sommaire : Mise à niveau de : 0. Installation de : 0, Supprimé : 1. Non mis à jour : 0 Espace libéré : 11,4 Mo Continuer ? [O/n]
        
        Le paquets marqués comme auto et qui ne sont plus utilisés sont proposés à le désinstallation, mais comme indiqué il faut le faire explicitement avec autoremove
        
        Pour l'exemple donné plus haut, python3-paraview est une recommendation (et ne devrait donc pas être installé automatiquement par défaut) et non une dépendance de paraview. On est clairement sur un cas particulier et peut-être une configuration particulière de APT.
        
        Répondre
        
        [^] # Re: Peut-être plus simple ?
        
        Posté par moi1392 le 23 octobre 2026 à 13:43. Évalué à 3 (+1/-0).
        
        je sais pas si c'est une erreur de frappe de ton coté, mais je parle du comportement de apt et non apt-get qui lui est différent en effet.
        
        Répondre
    - [^] # Re: Peut-être plus simple ?
      
      Posté par abriotde (site web personnel, Mastodon) le 19 octobre 2026 à 07:33. Évalué à 2 (+1/-1). Dernière modification le 19 octobre 2026 à 07:33.
      
      Pardon je n'avais pas vu. Mais il manque plein de fonctionnalités sur fait utd. Comme celle d'installer et de désinstaller seulement au redémarrage. Ça me semble une fonctionnalité essentielle. Car par exemple pour un nmap tu peux vouloir le lancer 2 ou 3 fois, surtout si au départ tu t'est trompé d'arguments.
      
      Mais c'est évident, au départ utd a été fait par bash mais ensuite, cela n'a pas suffit. Et pour cause, suivant l'outils d'install, il y a plein de cas à gérer… Et en bash cela devient vite impossible.
      
      Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
      
      Répondre
      - [^] # Re: Peut-être plus simple ?
        
        Posté par Dafyd le 19 octobre 2026 à 23:40. Évalué à 1 (+1/-1).
        
        Hello,
        
        Effectivement tout dépend du cahier des charges du programme.
        Moi si on me dit : il faut installer la commande si elle existe pas, la lancer, puis la désinstaller, OK.
        Maintenant, effectivement utd fait plus. Mais… Peut-être trop justement ? C'était le but de mon premier commentaire avec once qui tient en 3 lignes. utd fait un peu le café, mais passe peut-être à côté de la philosophie KISS. Cependant ! Disclaimer : c'est MON point de vue. 80% des fonctionnalités pour 20% de la complexité. Et on compose les programmes, au lieu de tenter de tout faire dans le même : install, désinstall, rootless, bubblewarp, et j'en passe.
        Après… Chacun programme comme il l'entend, je n'ai pas de jugement de valeur. Juste un désaccord philosophique :D
        
        Répondre
        
        [^] # Re: Peut-être plus simple ?
        
        Posté par barmic 🦦 le 20 octobre 2026 à 10:00. Évalué à 1 (+0/-1).
        
        La désinstallation automatique qui permet de ne pas oublier, le fait de pouvoir le lancer en simple utilisateur et de ne pas impacter le reste du système. Ça me semble pas être tout à fait un "je refais pareil avec une ligne de shell".
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        Répondre
- [^] # Re: Peut-être plus simple ?
  
  Posté par djnet le 26 octobre 2026 à 18:19. Évalué à 2 (+2/-0).
  
  (which $1 &> /dev/null || brew install{mathjax} 1) && * ; brew remove $1
  
  Ici le brew remove est éxécuté dans tous les cas, non ?
  C.a.d. aussi si le paquet est déjà installé: ce ne me semble pas être le comportement attendu !
  
  Répondre
  - [^] # Re: Peut-être plus simple ?
    
    Posté par Dafyd le 26 octobre 2026 à 19:36. Évalué à 2 (+1/-0).
    
    Oui complètement je m’étais déjà fait la remarque. Cependant, vu que j’ai bricolé ça en 5 mn et que l’idée n’était pas de pérenniser le projet j’ai pas poussé plus loin !
    
    Après on peut philosopher sur le sujet… finalement, on peut accepter que once désinstalle un paquet même s’il était déjà installé avant, car on souhaite désormais ne l’installer qu’à la demande :P
    
    Répondre
# 0install ?

Posté par karteum59 (site web personnel) le 18 octobre 2026 à 21:13. Évalué à 10 (+11/-0).

"de mon temps" il y avait 0install. ça a l'air de toujours exister…

Répondre
# Nix

Posté par François Chaix (Mastodon) le 19 octobre 2026 à 10:07. Évalué à 3 (+1/-0).
```
lol@test ~$ cowsay plop
zsh: command not found: cowsay
lol@test ~$ nix-shell -p cowsay --run "cowsay plop"                                                                                                                             
 ______
< plop >
 ------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
```
Répondre
- [^] # Re: Nix
  
  Posté par barmic 🦦 le 20 octobre 2026 à 10:02. Évalué à 2 (+1/-1).
  
  Nix est très bien, là c’est fait pour debian. J’utilise home-manager sur debian et si j’en suis globalement content je ne peux pas dire que ce soit parfait. Tu as des interactions des fois entre les libs système et nix qui cassent les paquets
  
  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
  
  Répondre
  - [^] # Re: Nix
    
    Posté par François Chaix (Mastodon) le 20 octobre 2026 à 11:25. Évalué à 2 (+1/-1).
    
    Ah, c'est intéressant. Je n'ai jamais observé ça.
    Ceci dit, le seul hôte non-nixos que j'utilise, c'est un WSL avec ubuntu + home-manager, et je n'y utilise que des outils en CLI. Tout le reste c'est du nixos, donc pas de risque de conflit avec des libs installées autrement que dans le store nix.
    
    Répondre
    - [^] # Re: Nix
      
      Posté par barmic 🦦 le 20 octobre 2026 à 13:45. Évalué à 0 (+0/-2).
      
      ouai moi je me sert d’home-manager pour répliquer de la conf entre mes machines Debian et le Mac du boulot et je te racompte pas la joie que ce fut d’installer wezterm avec une glibc (je crois que c’était ça) qui n’était pas compatible, mais les logiciels que je lance via mon wezterm doivent pas avoir l’override du chemin des bibliothèques.
      
      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
      
      Répondre