Nix ♥ la francophonie | 221 Members | |
| Salon francographe de NixOS | 72 Servers |
| Sender | Message | Time |
|---|---|---|
| 28 Apr 2023 | ||
| * Salut, Je suis en train de créer des paquets NURs, le dernier en date est Aviez vous rencontrer ce genre de problème ? | 22:32:54 | |
| Oui | 22:58:07 | |
| Y a un cache de tarbvall | 22:58:12 | |
| Donc si tu changes pas ton sha256, il y a une logique qui shortcut et utilise le fait que tes fixed output drvs sont "content addressed" donc on peut les retrouver juste avec le sha256 | 22:59:08 | |
| et du coup c'est confusant parce que t'es là en mode "ça va fail" mais en fait non, ça marche très bien parce qu'on a juste besoin du hash d'une FOD pour la retrouver | 22:59:31 | |
| le reste c'est superflu une fois que tu l'as déjà téléchargé | 22:59:37 | |
| 29 Apr 2023 | ||
| Hum, c'est moyen comme concept ! On nous bascine qu'avec #NixOS si tu as le même point d'entré, tu as la même sortie ! Ce qui dans ce cas est faux ! La j'avoue que sur ce point, ca me déçoit un peu ... Alors oui, je comprends le concept, mais étrange quand même d'accepter cela( ce n'est pas dramatique non plus ). Mais quand même. la mission du sha256 est justement de vérifier la cohérence des fichiers. Donc de ce que je comprends, peu importe le source, ils nomment le fichier En tout cas merci raitobezarius pour la réponse, je me douté plus ou moins que c'était cela, mais je ne voullais pas le croire (tellement ca me paraissait gros pour du immuable :) ) | 07:43:38 | |
je noterais que c'est exactement ce qui se passe. En spécifiant que le sha256 est le même, tu signifie que l'entrée est la même, et donc que la sortie doit être la même | 07:47:22 | |
*
je noterais que c'est exactement ce qui se passe. En spécifiant que le sha256 est le même, tu signifies que l'entrée est la même, et donc que la sortie doit être la même | 07:49:06 | |
Download 2023-04-29_09-49.png | 07:50:22 | |
| Hum .. pour moi l'entré, c'est la zone encadré en rouge, le sha256 est juste la pour vérifier que le contenu corespond à l'entré, c'est en tout cas comme ca que je le verais :) | 07:51:14 | |
| en général, c'est le cas, mais dans ce cas précis, ces informations sont "short-cicuitées", à partir du moment où le sha256 est le même dans deux cas de figure, c'est normal de considérer que le résultat est le même | 07:52:40 | |
| Bruno Adele: pour le nommage des chemins, il y a une PR ici: https://github.com/NixOS/nixpkgs/pull/153386 mais ça a l'air de causer beaucoup de breakage | 08:00:31 | |
| et il se trouve que avec cette PR, en changeant la version, le chemin est différent, et Nix ne suppose plus que le résultat est le même, donc ça réglerait ton autre soucis | 08:02:10 | |
et une explication de pourquoi ça a été nommé source à l'origine: https://github.com/NixOS/nixpkgs/pull/153386#issuecomment-1004715841 | 08:03:38 | |
| Merci Minijackson: pour ces précisions 👌💪 | 08:05:14 | |
| np! | 08:05:21 | |
In reply to @badele:matrix.org Je comprends ton pdv mais je pense que malgré que ça soit surprenant c'est un choix valide d'éviter de stocker plus d'une fois la même source dans le cache de 600TB en étant "modulo nom, version" mais ça a ses défauts :/ Je pense que ça devrait être gérer plus haut hors du store avec des asserts etc. | 10:59:13 | |
| petite note quand même: si tu veux vraiment ce comportement chez toi, tu peux toujours changer le nom de la dérivation
| 15:07:05 | |
Guillaume Desforges: je crois que fetchFromGithub accepte l'attribut name | 15:07:55 | |
| ah s'possible, je check | 15:08:07 | |
| indeed | 15:11:22 | |
| 15:14:14 | |
*
| 15:14:26 | |
In reply to @Minijackson:matrix.orgintéressant qu'il propose repo-rev plutôt que owner-repo ou owner-repo-rev | 15:16:37 | |
| j'imagine pour éviter de rebuild si jamais un dépôt change d'owner ? | 15:17:31 | |
| ah oui en cas de fork | 15:19:52 | |
| * ah oui en cas de fork par exemple | 15:20:04 | |