| 14 Dec 2025 |
 Martin | 25.05 | 11:17:19 |
 zbuben | du coup ça veut peut être le coup d'essayer… au niveau de ta configuration tu a mis un flake ou tu es sur le mode standard ? (avec des channels…) | 11:18:03 |
| Martin | standard | 11:18:26 |
| Martin | j'ai pas suivi, que permetrait le changement de version ? | 11:18:49 |
| zbuben | de te corriger les chemins horribles dans zef | 11:19:00 |
| Martin | ça marche, merci ! je pensais trouver une solution qui s'applique à chaque fois que je rencontre le soucis mais alors il faut plutôt le faire outil par outil | 11:23:30 |
| zbuben | c'est plutôt du côté du mainteneur que ça se passe en effet… après avec «un peu» d'habitude du langage nix, tu peux surcharger la définition d'un packet pour aller bricoler des trucs à l'intérieur et proposer des pr au mainteneur… | 11:25:12 |
| zbuben | la logique des packages nix tranche un peu avec la logique classique (et ressemble à la limite plus à celle de gentoo) … Tous les packages définis dans nixpkgs sont «source», et quand il se trouve que le packet est disponible dans un cache alors tu le prends en binaire… si tu changes des trucs qui nécessitent de le recompiler, alors ton système le fera directement. | 11:26:20 |
 bew | Ou les devs des programmes doivent 'juste' arrêter de dépendre sur les chemins, sur Nix ils sont long! Pour un affichage d'aide c'est vraiment le nom du binaire qu'il faut et pas tout son path.. | 11:26:47 |
 Jo.Blade | Ou alors, juste mettre [...] dans le nom s'il est trop mong | 11:27:44 |
| Jo.Blade | * | 11:27:50 |
| zbuben | oui, la solution upstream est aussi pas mal ;)
Mais bon, toutes les petits astuces genre #!/usr/bin/env bash au début des scripts, c'est pas trop l'habitude, et c'est quand même très souvent les mainteneurs nixpkgs qui se coltinent l'adaptation | 11:27:54 |
