<lsix>
ah non, c’estsurtout que je lis mal ^_^ j’ai lu `qui est dans le path`…
<lsix>
du coup (et il peux y avoir plusieurs hit): `echo /nix/store/*/bin/<le_prog>` est une bonne prempère approximation
<gordon>
je suis toujours en phase d’apprentissage/compréhention de NixOS. J’ai rencontré mon premier cas de « je télécharge un binaire, oups il s’exécute pas, avec la pire erreur au monde », AKA chemin invalide du dynamic-loader. D’abord, je ne comprends pas pourquoi le loader n’est pas symlinké à son emplacement habituel ?
<gordon>
ensuite, est-ce que je comprends bien le cas en « il faut que tout soit packagé par nix pour fonctionner correctement » ? Est-ce que ça ne pose pas de problème pour les applications non libres ? Typiquement, sous steam, j’ai plusieurs jeux qui segfaultent au bout d’une seconde quand lancés avec `steam-run`, est-ce qu’on peut y faire quelque chose ?
<symphorien>
les garanties que nixos apportent sont liées au fait que toutes les dépendences sont explicites par chemin absolu dans le store. Un dynamic loader global à un emplacement unique est incompatible avec cette approche.
<gordon>
donc l’utilisation de binaires distribués est à proscrire complètement ?
<symphorien>
y'a autopatchelf qui peut aider mais c'est pas facile du tout
<symphorien>
*autopatchelfhook
<gordon>
ah
<symphorien>
en moyenne, si la source est disponible c'est souvent plus facile de s'en servir
<gordon>
j’ai regardé patchelf, mais la doc est très rudimentaire
<symphorien>
sauf cas particulier comme électron
<gordon>
ah
<symphorien>
et pour les jeux, je ne sais pas, mais totu n'est pas rose
<gordon>
est-ce qu’en construisant un programme depuis ses sources dans un environnement nix (mais pas avec nix, genre directement `make`), il trouvera les bons chemins dans le store, ou est-ce qu’il faut patcher les sources avant ?
<symphorien>
les programmes traditionnels (./configure; make; make install) fonctionnent raisonnablement bien quand ils sont compilés dans nix-shell
<symphorien>
(aucun compilateur fourni par nix ne marche en dehors de nix-shell)
<gordon>
ok
<symphorien>
par contre, ils cesseront de fonctionner après que leur dépendences sont supprimées avec nix-collect-garbage
<symphorien>
donc nix-shell est bien pour le développement, mais pas pour l'installation long terme.
<gordon>
ok, mais c’est utile pour vérifier si le programme se compile, dans l’optique de faire une dérivation reproductible, c’est ça ?
<symphorien>
voilà. Ou tout simplement en tant que développeur.
<gordon>
et en quoi electron est différent ? autopatchelf fonctionne tel quel dessus ?
<symphorien>
compiler électron depuis la source est très difficile
<symphorien>
autopatchelf marche dessus, c'est comme ça qu'il est dans nixpkgs
<gordon>
ok
<genesis>
symphorien : le truc marrant c'est que j'ai decouvert nixos par patchelf, parce que je contribuais a appimage
<genesis>
je cherchais des solutions a nos pbs, j'ai decouvert le projet nix, j'ai abandonné appimage :-)
<genesis>
eux ils sont forts @appimage, ils utilisent patchelf mais sont meme pas curieux de tester nix
<genesis>
des fanas de NIH.
<genesis>
gordon : perso je commence tjs par faire la dérivation
<genesis>
mais nix-shell c'est super, mais quand on envisage de developper sur le soft, pour faire fonctionner un soft c'est pas une bonne habitude a prendre, autant faire la dérivation, au pire avec -K pour voir un peu ce qui a mrdé dans les sources, quitte a faire un nix-shell dans le répertoire temporaire
<genesis>
si on s'en sort pas via la derivation.
<genesis>
(-K sur nix-env)
<genesis>
et patchelf c'est pas dur du tout, suffit de matter les nombreux examples dans nixpkgs.
<genesis>
ca va juste modifier le chemin des liens symboliques, ca casse pas 3 pattes a un canard.
<gordon>
laissons les canards tranquilles :<
<genesis>
ok.
<gordon>
oh, je viens de comprendre une chose : les timestamps à 0 sur tout ce qui est dans /nix/store, c’est pour la reproductibilité ?
<gordon>
(le point d’interrogation est purement décoratif)
<samueldr>
oui
<gordon>
c’était la découverte du soir, bonne nuit x)