Nix For Lang Packaging: Difference between revisions
imported>Nyarly No edit summary |
imported>Vater mNo edit summary |
||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{Merge|Nix Expression Language|Article is essentially an introduction to the nix language}} | |||
= Overview = | = Overview = | ||
| Line 103: | Line 104: | ||
Another difficulty is that because the `.git` folder is not guaranteed to have exactly the same content between clones (due to changes to the pack files), it makes it hard to always get the sha256. In most cases the `.git` folder can be removed to avoid these differences but it's not always possible. For example if the repo needs git submodules, or if the build system invokes `git` to find out repo metadata that get included in the build output, then the `.git` folder needs to be kept. | Another difficulty is that because the `.git` folder is not guaranteed to have exactly the same content between clones (due to changes to the pack files), it makes it hard to always get the sha256. In most cases the `.git` folder can be removed to avoid these differences but it's not always possible. For example if the repo needs git submodules, or if the build system invokes `git` to find out repo metadata that get included in the build output, then the `.git` folder needs to be kept. | ||
In the | In the GitHub case (and probably Bitbucket, GitLab, ...), the service also provides tarballs of specific hashes. Regularly the tarball output is also changed so nixpkgs resorts on hashing the unpacked content instead. | ||
All this means that there are many possible variations and it's going to be hard to agree on which-one is the best. | All this means that there are many possible variations and it's going to be hard to agree on which-one is the best. | ||
| Line 115: | Line 116: | ||
* ... | * ... | ||
[[Category: | [[Category:Tutorial]] | ||
[[Category:Development]] | [[Category:Development]] | ||
[[Category:Nixpkgs]] | [[Category:Nixpkgs]] | ||