Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
c2384052e3 | ||
|
|
47ed06a290 | ||
|
|
2142f47c06 | ||
|
|
4e0607369e | ||
|
|
8bdff8c100 | ||
|
|
14955c297d | ||
|
|
68b4717873 | ||
|
|
6466d56f42 | ||
|
|
e90e7b5e0a | ||
|
|
eb53f592b8 | ||
|
|
9c830394ec | ||
|
|
4c4e891652 | ||
|
|
be79773542 | ||
|
|
4eace5adda | ||
|
|
751ae181a1 | ||
|
|
3b88d03714 | ||
|
|
e5a51fab24 | ||
|
|
fa2063ca35 | ||
|
|
c2a552b075 | ||
|
|
b77037b8fd | ||
|
|
46f3eb6fdd | ||
|
|
f52b6c944e | ||
|
|
28f22b4653 | ||
|
|
5a2d451648 | ||
|
|
54616be64f | ||
|
|
4acca1a5b9 | ||
|
|
ad790022fd | ||
|
|
dcdb254281 | ||
|
|
df319047f4 | ||
|
|
8aedaf111e | ||
|
|
a144eb1415 | ||
|
|
40e1203abc | ||
|
|
6f8ff8564f | ||
|
|
c56bfbe863 | ||
|
|
851b47bd7d | ||
|
|
0e8fc118b3 | ||
|
|
b5ed5b6e66 | ||
|
|
20cf0127f5 | ||
|
|
e529823635 | ||
|
|
ad332e1718 | ||
|
|
36c6786036 | ||
|
|
938454d8f3 | ||
|
|
2e98703c0c | ||
|
|
50c3352811 | ||
|
|
2f16946064 | ||
|
|
39fe52f7ac | ||
|
|
af555d7694 | ||
|
|
d44d923be9 | ||
|
|
5510d21193 | ||
|
|
e5891f2ea8 | ||
|
|
f665c5d9b3 | ||
|
|
4872677ffa | ||
|
|
936f68668c | ||
|
|
629e8da3aa | ||
|
|
9c58691ce3 | ||
|
|
b6f99e5a23 | ||
|
|
8d169b2b75 | ||
|
|
d34d2b2bbf | ||
|
|
d51eed833a | ||
|
|
bf78a27ac9 | ||
|
|
f43a8ede93 | ||
|
|
608110804c | ||
|
|
320659b0cd | ||
|
|
5f04da905f | ||
|
|
d4c8ee7059 | ||
|
|
976df480c9 | ||
|
|
4e340a983f | ||
|
|
976b949e4d | ||
|
|
b7b6e3ddec | ||
|
|
9e3389c337 | ||
|
|
215745415e | ||
|
|
103e4e43cc | ||
|
|
2b74354e52 | ||
|
|
5e04992d1f | ||
|
|
69f91e3645 | ||
|
|
328a80e60a | ||
|
|
b0c5c2ac34 | ||
|
|
fe37ed1219 | ||
|
|
048ec3d3f2 | ||
|
|
05cddf0f5a | ||
|
|
8299aaf079 | ||
|
|
a3e5c99d66 | ||
|
|
1256ab3b44 | ||
|
|
ed306febb5 | ||
|
|
5d064e2698 | ||
|
|
35aad73bb6 | ||
|
|
2719627bbe | ||
|
|
3d604ac88c | ||
|
|
997defa166 | ||
|
|
8cfe939b0f | ||
|
|
5ef2453139 | ||
|
|
bab8d9b52a | ||
|
|
d436e44ae3 | ||
|
|
087581a642 | ||
|
|
8979562ed7 | ||
|
|
06a86aee15 | ||
|
|
3cc9977118 | ||
|
|
bbf294cceb | ||
|
|
6f6b75cd09 | ||
|
|
526811c87a | ||
|
|
e389f4ea55 | ||
|
|
1cdbb9d724 | ||
|
|
1d02431b60 | ||
|
|
3a9b4a1467 | ||
|
|
80893a13a7 | ||
|
|
a51f8d6747 | ||
|
|
f72944b42f | ||
|
|
1683fffd09 | ||
|
|
722bd041ce | ||
|
|
11aef17a77 | ||
|
|
5f7ded7d22 | ||
|
|
89e3b52755 | ||
|
|
29f7e142fc | ||
|
|
6062b12160 | ||
|
|
f040159f77 | ||
|
|
ecc2c8f464 | ||
|
|
84a13dc576 | ||
|
|
d16e3c7f09 | ||
|
|
bca6d35636 | ||
|
|
138c257dcd | ||
|
|
fb4e216598 | ||
|
|
bc4795919a | ||
|
|
d04e1ff12a | ||
|
|
2c1711ae33 | ||
|
|
c6849e2dee | ||
|
|
a8925a510c | ||
|
|
f1adf4c998 | ||
|
|
a79e56de68 | ||
|
|
2a4dbcff74 | ||
|
|
6bb4c0b712 | ||
|
|
986fbd6fab | ||
|
|
b6809608cc | ||
|
|
1418806969 | ||
|
|
c3f0a489f9 | ||
|
|
d4fcbe1687 | ||
|
|
58d8a213b0 | ||
|
|
3f8576a6ab | ||
|
|
c08c802bf3 | ||
|
|
3fd2d2187e | ||
|
|
3b5fa8d50c | ||
|
|
104e55bb7f | ||
|
|
3800f441e4 | ||
|
|
a17c23426e | ||
|
|
d61853430a | ||
|
|
f77be20c16 | ||
|
|
9b146a52f1 | ||
|
|
0ed1b924be | ||
|
|
e83a027e00 | ||
|
|
13a18ceb44 | ||
|
|
147fcdd137 | ||
|
|
cf72a61af2 | ||
|
|
9dd54bc7bb | ||
|
|
a5b5ebc45f | ||
|
|
c313d86bb8 | ||
|
|
ebb1dbb3e1 | ||
|
|
570571a2b7 | ||
|
|
53b044c2f6 | ||
|
|
0cd6596b0e | ||
|
|
831fc8ea21 | ||
|
|
1e0a799bef | ||
|
|
022618c794 | ||
|
|
a54c263402 | ||
|
|
eff120d1b9 | ||
|
|
68cf98c4d2 | ||
|
|
2d6cd8aafd | ||
|
|
ea525a261f | ||
|
|
93e4f01ee3 | ||
|
|
5b58991a71 | ||
|
|
0342eb1705 | ||
|
|
726abdecfb | ||
|
|
7d7b67986a | ||
|
|
d4a71ec3bf | ||
|
|
8be9990cdb | ||
|
|
d64b8e9e53 | ||
|
|
d98bfcbf81 | ||
|
|
5a05cf4063 | ||
|
|
6e5b02bee4 | ||
|
|
d37d012774 | ||
|
|
eca29bd72d | ||
|
|
a2fc9c6b57 | ||
|
|
3a52104bee | ||
|
|
5a0181c7f2 | ||
|
|
f77d83c26b | ||
|
|
3c8522cc22 | ||
|
|
54adf344a3 | ||
|
|
7a740c9288 | ||
|
|
b1af336132 | ||
|
|
57f6463ec0 | ||
|
|
d0608da13f | ||
|
|
8b760182cd | ||
|
|
f271b94652 | ||
|
|
7a68b4e4d3 | ||
|
|
9ed49c1da0 | ||
|
|
8259a392da | ||
|
|
f0ef6b74b9 | ||
|
|
67e5dd3ce9 | ||
|
|
72d684d592 | ||
|
|
5c4d2dab99 | ||
|
|
9648222ef0 | ||
|
|
44e7e3bb9b | ||
|
|
075cfe3b97 | ||
|
|
afbdd55334 | ||
|
|
d2d5543625 | ||
|
|
a6a45bb722 | ||
|
|
f8df935102 | ||
|
|
e74113a305 | ||
|
|
9d65287b91 | ||
|
|
22c900da08 | ||
|
|
9472b4157d | ||
|
|
8fb8c26b6d | ||
|
|
27a01d92c2 | ||
|
|
b72e93bca8 | ||
|
|
9eddf6f0b6 | ||
|
|
b5da80e627 | ||
|
|
fd61069a42 | ||
|
|
8901acc976 | ||
|
|
3f0a4bf0e7 | ||
|
|
4b0a720ddf | ||
|
|
b224ac1520 | ||
|
|
3f80060500 | ||
|
|
809ca33806 | ||
|
|
163fdf292e | ||
|
|
524f89f139 | ||
|
|
fefd3650d4 | ||
|
|
65243ee833 | ||
|
|
43579c9799 | ||
|
|
9481f77693 | ||
|
|
c93690a68a | ||
|
|
2aa93858af | ||
|
|
ab4eba5b91 | ||
|
|
f0610e28e8 | ||
|
|
11849a320e | ||
|
|
373fad75e1 | ||
|
|
392430b2c4 | ||
|
|
894fa5e42d | ||
|
|
954188af27 | ||
|
|
029424d17d | ||
|
|
02843ba4cb | ||
|
|
632f989b51 | ||
|
|
c160ead82f | ||
|
|
42e9ad8fd1 | ||
|
|
c6e85ee474 | ||
|
|
ccd4fe5c49 | ||
|
|
ad716378dc | ||
|
|
3e5dbb2433 | ||
|
|
3bea429ae8 | ||
|
|
fde819f2e2 | ||
|
|
cb921f67c3 | ||
|
|
e9b609bf9a | ||
|
|
9367046fef | ||
|
|
5f05197df4 | ||
|
|
47e185847e | ||
|
|
5bed74d1b0 | ||
|
|
401ab50566 | ||
|
|
57695d8f76 | ||
|
|
6e1f4c1488 | ||
|
|
393a9b92b1 | ||
|
|
a6f4554656 | ||
|
|
4a198dae74 | ||
|
|
98873ff7de | ||
|
|
f02c52e3d4 | ||
|
|
988bf59421 | ||
|
|
daccd68999 | ||
|
|
7018830509 | ||
|
|
d5a076c36f | ||
|
|
4d73e2e893 | ||
|
|
bb45092f72 | ||
|
|
7a60ff9a62 | ||
|
|
51485dcda2 | ||
|
|
4c4b219c07 | ||
|
|
eea0401d7a | ||
|
|
e0d7d0e45c | ||
|
|
daf3f2c11f | ||
|
|
1c208f2b7e | ||
|
|
50dc1f5b71 | ||
|
|
45f9a91e18 | ||
|
|
3d221a7bb1 | ||
|
|
2ea2703fe9 | ||
|
|
50ed345fad | ||
|
|
13a63b59bb | ||
|
|
67937907ca | ||
|
|
71a20d4d95 | ||
|
|
1a44f1cb65 | ||
|
|
7f7d4ab686 | ||
|
|
17ef234672 | ||
|
|
7b351da680 | ||
|
|
03103c0a36 | ||
|
|
62309a2c56 | ||
|
|
56131a2709 | ||
|
|
01ddf53ee9 | ||
|
|
d7a92ed4a9 | ||
|
|
a6ab3cf35f | ||
|
|
0fae20c362 | ||
|
|
aa1560ca07 | ||
|
|
24c6d992c6 | ||
|
|
1eb0af7ed5 | ||
|
|
d3c61d83be | ||
|
|
62ad3dfc43 | ||
|
|
bd91453bb1 | ||
|
|
ece531d105 | ||
|
|
d0fad1779f | ||
|
|
78224cd871 | ||
|
|
49fe9592a4 | ||
|
|
fdee1ced43 | ||
|
|
5989966ed3 | ||
|
|
ee3c5d7916 | ||
|
|
2e77bd70fa | ||
|
|
f609eec71a | ||
|
|
8ddffe7aac | ||
|
|
049c0eb49c | ||
|
|
0c730887c4 | ||
|
|
77c972c898 | ||
|
|
8f72e702a1 | ||
|
|
2304a7dd21 | ||
|
|
985f1595fe | ||
|
|
276a40b31f | ||
|
|
bb65460feb | ||
|
|
de8be7c3e0 | ||
|
|
048be62484 | ||
|
|
a2c85b2ef8 | ||
|
|
5bcb982711 | ||
|
|
fa13d3f4f3 | ||
|
|
b2e0293f02 | ||
|
|
a00a98548e | ||
|
|
838138c5c4 | ||
|
|
a5c6347ff0 | ||
|
|
b8f24f2535 | ||
|
|
e196eecbe6 | ||
|
|
d0eb970fb4 | ||
|
|
edbfe2232e | ||
|
|
42d91b079c | ||
|
|
7bb632b024 | ||
|
|
7c3a5090bf | ||
|
|
43b64f5038 | ||
|
|
8e9140cfde | ||
|
|
1114c7bd57 | ||
|
|
7911e4c27a | ||
|
|
04170d06bf | ||
|
|
2c3a8f787b | ||
|
|
66dbc0fdee | ||
|
|
0e5d0c1543 | ||
|
|
beac05c206 | ||
|
|
beaf3e90af | ||
|
|
e82951fe23 | ||
|
|
e477f0e938 | ||
|
|
858b8f9760 | ||
|
|
8504e7d604 | ||
|
|
d7be6d45d9 | ||
|
|
d62f46e500 | ||
|
|
5cd022d6c0 | ||
|
|
9d0709e8c4 | ||
|
|
48495f67ed | ||
|
|
0960d674d4 | ||
|
|
718f20da6d | ||
|
|
a8fb575c98 | ||
|
|
61c464f252 | ||
|
|
ee7fe64c0a | ||
|
|
b1beed97a0 | ||
|
|
829af22759 | ||
|
|
3c6b8a5215 | ||
|
|
ceed819284 | ||
|
|
becc2b0167 | ||
|
|
54a34119f3 | ||
|
|
a457d5ad4d | ||
|
|
b1d39d4765 | ||
|
|
8ea9fd7aa6 | ||
|
|
d8c061e044 | ||
|
|
62a6eeb1f3 | ||
|
|
39d72640c2 | ||
|
|
a8edf185a9 | ||
|
|
c273c15cb1 | ||
|
|
f0fdbd0897 | ||
|
|
0321ef9bb2 | ||
|
|
3064a82156 | ||
|
|
9f9080e2c0 | ||
|
|
eac5841970 | ||
|
|
8d5f472f2c | ||
|
|
84813af5b9 | ||
|
|
690adeb03d | ||
|
|
a1b66f316e | ||
|
|
3b9ea8452f | ||
|
|
d73ffc552f | ||
|
|
e384e7b387 | ||
|
|
e974f20c98 | ||
|
|
36662eb562 | ||
|
|
95501c4dee | ||
|
|
a55e77ae10 | ||
|
|
a84f503d86 | ||
|
|
aa9b1cf48e | ||
|
|
2c4affbaa8 | ||
|
|
93506e60d2 | ||
|
|
40250f23a0 | ||
|
|
6dd1087396 | ||
|
|
a8c31d5011 | ||
|
|
696f960dee | ||
|
|
20668b1363 | ||
|
|
de4cdd0d47 | ||
|
|
ada3e3fa15 | ||
|
|
eeffdb74dc | ||
|
|
31fe55bb8e | ||
|
|
700c678c2e | ||
|
|
fb5d76b89e | ||
|
|
a1917208c0 | ||
|
|
742933116f | ||
|
|
924e19341a | ||
|
|
b0a09a6f32 | ||
|
|
dfa2f77d2e | ||
|
|
e0a947cde6 | ||
|
|
d23931f3a4 | ||
|
|
4846005741 | ||
|
|
2b6c8ef401 | ||
|
|
76cbf55a6d | ||
|
|
89f9232813 | ||
|
|
84d6936371 | ||
|
|
8e5fbf4d73 | ||
|
|
4c5faad994 | ||
|
|
bd9b1d97b4 | ||
|
|
8160f794e7 | ||
|
|
a5fe730940 | ||
|
|
27b44b8cf7 | ||
|
|
96b695ccab | ||
|
|
b62d36963c | ||
|
|
c28de6d96e | ||
|
|
8b31ffd10d | ||
|
|
b72c8d2e5b | ||
|
|
3f8e1f5682 | ||
|
|
1f19fdbd45 | ||
|
|
ae6b631dc4 | ||
|
|
daa16cca11 | ||
|
|
7191a7394a | ||
|
|
f0de86357c | ||
|
|
e7720aa10a | ||
|
|
ac6ceea764 | ||
|
|
034b6f6062 | ||
|
|
7ef7597f71 | ||
|
|
59c9019685 | ||
|
|
1c2550a2ae | ||
|
|
9becaa041f | ||
|
|
acb8facbbc | ||
|
|
90dc50b07c | ||
|
|
49009573bc | ||
|
|
24cb65efc3 | ||
|
|
3fc056927c | ||
|
|
51800e06de | ||
|
|
f93e97517e | ||
|
|
77e2cc6c8e | ||
|
|
fb8d8f5428 | ||
|
|
006f24c7fa | ||
|
|
d435e46daa | ||
|
|
e9934bb5ad | ||
|
|
25386e5edc | ||
|
|
92a848f674 | ||
|
|
2f2a20ed18 | ||
|
|
049a379ec6 | ||
|
|
908e9ce259 | ||
|
|
2caab81660 | ||
|
|
f7e077ad27 | ||
|
|
d6a45f6bdb | ||
|
|
a376762848 | ||
|
|
3a86888fd7 | ||
|
|
4eac3b2471 | ||
|
|
4e7e498ff9 | ||
|
|
1017bd68ea | ||
|
|
3fd01b171a | ||
|
|
c9f6232304 | ||
|
|
29cde917fe | ||
|
|
7c7707638a | ||
|
|
7880973827 | ||
|
|
5ad263c26b | ||
|
|
3d0a9ec825 | ||
|
|
91f25f0510 | ||
|
|
432328cc55 | ||
|
|
509993e598 | ||
|
|
d58ceae022 | ||
|
|
7bbc68fdff | ||
|
|
a0806389e9 | ||
|
|
a9c4a98770 | ||
|
|
045d3b2ed7 | ||
|
|
fac6f8aac0 | ||
|
|
84143c4bd8 | ||
|
|
19437785eb | ||
|
|
fdff3a7eae | ||
|
|
506d86394d | ||
|
|
6b9cd59a41 | ||
|
|
7f74513b4e | ||
|
|
00d761016a | ||
|
|
d761009e3c | ||
|
|
f14ef84a51 | ||
|
|
733214144a | ||
|
|
42eb4afd7a | ||
|
|
bf4a577a58 | ||
|
|
8a02fdc38e | ||
|
|
dcaea042fc | ||
|
|
df5de9dfd7 | ||
|
|
36b90e72d7 | ||
|
|
a897b58373 | ||
|
|
e1cf40fa95 | ||
|
|
c31836008e | ||
|
|
e707a8a526 | ||
|
|
73f74ebba0 | ||
|
|
a7e70518b8 | ||
|
|
70a558e202 | ||
|
|
7bef965d6f | ||
|
|
79f699edca | ||
|
|
8129cf33d9 | ||
|
|
1aa19b24b2 | ||
|
|
4ec626a286 | ||
|
|
99f14c2584 | ||
|
|
b6def5b542 | ||
|
|
dfbcb7c403 | ||
|
|
71adb090f0 | ||
|
|
69fe6c58fa | ||
|
|
1da6ae4f99 | ||
|
|
00d30496ca | ||
|
|
e81d38c02b | ||
|
|
832377bbd6 | ||
|
|
581a160c11 | ||
|
|
a9d99ab55f | ||
|
|
4db572062c | ||
|
|
dba33d4018 | ||
|
|
61fd494d76 | ||
|
|
f67f52751f | ||
|
|
62eb9eb76d | ||
|
|
7438f0bc2b | ||
|
|
2246aa77d2 | ||
|
|
f9fc6acbf4 | ||
|
|
a35c6eb4a2 | ||
|
|
1f841c9d50 | ||
|
|
57386c9bae | ||
|
|
c89d6b9b63 | ||
|
|
38c3beac1a | ||
|
|
1614603165 | ||
|
|
78d979567f | ||
|
|
c5839752b9 | ||
|
|
b632153ebd | ||
|
|
64e23d0a38 | ||
|
|
5671188eb2 | ||
|
|
73874629ef | ||
|
|
188f96500b | ||
|
|
9488447594 | ||
|
|
3a38d0f356 | ||
|
|
84a8b5e9af | ||
|
|
e4058fab64 | ||
|
|
0c3e8a616e | ||
|
|
0432bc52ea | ||
|
|
7fab23e237 | ||
|
|
764d90597a | ||
|
|
a210c995cd | ||
|
|
97f8e9bc76 | ||
|
|
2a469ad31d | ||
|
|
1f94ec3924 | ||
|
|
20d0598928 | ||
|
|
4161fce472 | ||
|
|
80b691316c | ||
|
|
4ee6001f95 | ||
|
|
0da82efa5d | ||
|
|
143224f7cd | ||
|
|
d210cdc435 | ||
|
|
73a775f3b7 | ||
|
|
8468806552 | ||
|
|
d6582c04c1 | ||
|
|
2f9bb5c7e7 | ||
|
|
6dca72006a | ||
|
|
2a97f7b039 | ||
|
|
965218a62a | ||
|
|
b6465ae5d3 | ||
|
|
762ef464f8 | ||
|
|
28dc488335 | ||
|
|
844d83352c | ||
|
|
74ca70da3a | ||
|
|
6ef32bddc1 | ||
|
|
1eff3ad37f | ||
|
|
6f8aa145d4 | ||
|
|
0c6d62cf27 | ||
|
|
16e7d69209 | ||
|
|
ec1738589a | ||
|
|
35107038f7 | ||
|
|
f324b49ea1 | ||
|
|
ac8c2ef1aa | ||
|
|
4271927c5b | ||
|
|
e0234dfddc | ||
|
|
4a2ec9c659 | ||
|
|
c5ba081333 | ||
|
|
79dee4283d | ||
|
|
7fdee6e136 | ||
|
|
5311b2b250 | ||
|
|
94f9c14d52 | ||
|
|
a26307b281 | ||
|
|
625ffd441d | ||
|
|
68cde53c47 | ||
|
|
81628a6ccc | ||
|
|
5ef8508a92 | ||
|
|
c8fff6a77f | ||
|
|
0e2ca26818 | ||
|
|
0f2f44bb0f | ||
|
|
bf0ad8aabc | ||
|
|
f5e5793cd2 | ||
|
|
f9913f4422 | ||
|
|
e640d67144 | ||
|
|
f1357059a4 | ||
|
|
ea59f39326 | ||
|
|
ca73c0102f | ||
|
|
e991ab942b | ||
|
|
b1db599dd0 | ||
|
|
cf918b889b | ||
|
|
70d8e8fdde | ||
|
|
814a73227f | ||
|
|
b4c684e0f9 | ||
|
|
568b1b0a8a | ||
|
|
55c9a40613 | ||
|
|
f4013b6189 | ||
|
|
ea38e39a20 | ||
|
|
11cb4bfb25 | ||
|
|
0fdf4da0e9 | ||
|
|
405434e084 | ||
|
|
7a61c88dbb | ||
|
|
485f4740ee | ||
|
|
fe23e28f12 | ||
|
|
4252b5a645 | ||
|
|
cd49fe4f9b | ||
|
|
6f3a51809a | ||
|
|
18fefacf7d | ||
|
|
136f2f7046 | ||
|
|
5ba5993470 | ||
|
|
b352fe2775 | ||
|
|
8931bf7168 | ||
|
|
f1e5dedb61 | ||
|
|
7d203faff6 | ||
|
|
194e3374b8 | ||
|
|
769f662165 | ||
|
|
0c1198cf08 | ||
|
|
65a6452240 | ||
|
|
259086de84 | ||
|
|
99ed25accf | ||
|
|
7b0d8fb23d | ||
|
|
088552b319 | ||
|
|
e81b82a2cf | ||
|
|
a630635d7f | ||
|
|
4da8046513 | ||
|
|
034bbcafaf | ||
|
|
45131da736 | ||
|
|
c34f3c5ba4 | ||
|
|
dfcc64f556 | ||
|
|
3560f52cc4 | ||
|
|
49a385096e | ||
|
|
e36229d27f | ||
|
|
22d665019a | ||
|
|
a6add93d73 | ||
|
|
c5b8fe3151 | ||
|
|
bf8b66adcf | ||
|
|
f3cf0436b5 | ||
|
|
0202ce6b94 | ||
|
|
9285f0aa2b | ||
|
|
8f08046606 | ||
|
|
7ce0e05ad8 | ||
|
|
962551a071 | ||
|
|
1a1d8b073a | ||
|
|
784feb6839 | ||
|
|
cac06ed0a4 | ||
|
|
b225ccb654 | ||
|
|
0c504a756c | ||
|
|
2cc591c7b5 | ||
|
|
79b7c596a9 | ||
|
|
ed0a8dd71a | ||
|
|
f980755766 | ||
|
|
e9b6397d2f | ||
|
|
4315acb8c0 | ||
|
|
c7547cff19 | ||
|
|
2bd0fcc966 | ||
|
|
f267ff16b4 | ||
|
|
abb5bd66de | ||
|
|
07c87a8e9e | ||
|
|
c1f3a1a89b | ||
|
|
5a1114ecdb | ||
|
|
06a8ac96e7 | ||
|
|
90dfb37f14 | ||
|
|
14772783e6 | ||
|
|
611868a909 | ||
|
|
d1b3ca0b4a | ||
|
|
6dd74b48f8 | ||
|
|
9b11a8bfbc | ||
|
|
812b5a30ec | ||
|
|
ea2f7df5fa | ||
|
|
6b5f89f2cf | ||
|
|
754c05ed6c | ||
|
|
9a14d5e2f3 | ||
|
|
ffdc85fc8a | ||
|
|
62e35cc3a8 | ||
|
|
eff6c4b791 | ||
|
|
e0a108b203 | ||
|
|
eaf903f993 | ||
|
|
1474ecfe42 | ||
|
|
bc96c4518e | ||
|
|
b8e9efc476 | ||
|
|
709cbe4e76 | ||
|
|
d4a76ff0e4 | ||
|
|
30b986908e | ||
|
|
0f24400d90 | ||
|
|
990126cde0 | ||
|
|
af94a70ba6 | ||
|
|
245e26408f | ||
|
|
5fea98111b | ||
|
|
77c13cdf56 | ||
|
|
285df765b9 | ||
|
|
fc33fd86b7 | ||
|
|
90b5e69284 | ||
|
|
a478e8a7bb | ||
|
|
89e6781cc5 | ||
|
|
2bcb384e95 | ||
|
|
c897bac549 | ||
|
|
273322c773 | ||
|
|
4badd7ed17 | ||
|
|
8d6418d46e | ||
|
|
dec2f19502 | ||
|
|
6123144933 | ||
|
|
1dacd427cd | ||
|
|
ea6bf0c21f | ||
|
|
36e67ff16b | ||
|
|
fba17a9043 | ||
|
|
2d9bb56e55 | ||
|
|
5bc41d78ff | ||
|
|
9e4bb20455 | ||
|
|
dc341811d6 | ||
|
|
69befd33a9 | ||
|
|
a5684e09d3 | ||
|
|
411a3461dc | ||
|
|
05d02f798f | ||
|
|
6da92d96ae | ||
|
|
543d8a5942 | ||
|
|
fe95650487 | ||
|
|
3139481822 | ||
|
|
c086183843 | ||
|
|
4f4a14453a | ||
|
|
4ea034a5c5 | ||
|
|
792fd51f41 | ||
|
|
f440558acc | ||
|
|
bb659bad81 | ||
|
|
f6a8e7f4c2 | ||
|
|
b08f4b0da9 | ||
|
|
d7625b5c2d | ||
|
|
b8034e5581 | ||
|
|
9d8a80375d | ||
|
|
d6a7aa8f48 | ||
|
|
b8571d68c4 | ||
|
|
a737f51fd9 | ||
|
|
ff02f5336c | ||
|
|
4bd5282573 | ||
|
|
bce14d0f61 | ||
|
|
7cdefdbe73 | ||
|
|
d05bf04444 | ||
|
|
c1994fecf9 | ||
|
|
672c3acc71 | ||
|
|
7bdb85453d | ||
|
|
9deb822180 | ||
|
|
b1e3b1a4ac | ||
|
|
6b47de580f | ||
|
|
a5e0f64db3 | ||
|
|
221a2daf34 | ||
|
|
176c666f36 | ||
|
|
c945f015de | ||
|
|
28e0742966 | ||
|
|
a5fb4b5b7c | ||
|
|
faaae44f2e | ||
|
|
f53574ebd6 | ||
|
|
d5529f5b85 | ||
|
|
b072fc04a7 | ||
|
|
fecad91b67 | ||
|
|
0220da3e10 | ||
|
|
936f9d45ba | ||
|
|
4b83830d0c | ||
|
|
5904262640 | ||
|
|
2c1ecf8e81 | ||
|
|
88c07341a6 | ||
|
|
07a08bddf0 | ||
|
|
c57ed84e28 | ||
|
|
ef4f5ba85e | ||
|
|
06bb2d95b4 | ||
|
|
6f809194d7 | ||
|
|
57d18df7d0 | ||
|
|
92077b4547 | ||
|
|
33972629d7 | ||
|
|
ac1b754138 | ||
|
|
c28dfc0305 | ||
|
|
e9b92169a5 | ||
|
|
ecd830b3b9 | ||
|
|
6ec8dab06a | ||
|
|
b29d3f4aee | ||
|
|
efe4289464 | ||
|
|
afc6c1bad6 | ||
|
|
6cd6ce5608 | ||
|
|
34bb806f74 | ||
|
|
c6c024ca6f | ||
|
|
03eaef3d7a | ||
|
|
b3110a15e9 | ||
|
|
25a108bb9c | ||
|
|
d308aeaf53 | ||
|
|
297b762513 | ||
|
|
46222bbc43 | ||
|
|
58204a3c39 | ||
|
|
3fb7ae0586 | ||
|
|
161a2ccf7a | ||
|
|
a583a2bc59 | ||
|
|
263d668222 | ||
|
|
fd7d979c79 | ||
|
|
46ffcce0c3 | ||
|
|
8e74c0bfd1 | ||
|
|
3d77b28eac | ||
|
|
47701677e8 | ||
|
|
5d147e125c | ||
|
|
159e621d1a | ||
|
|
511455965e | ||
|
|
7df4ef983e | ||
|
|
0a470fc345 | ||
|
|
8ae6d55db1 | ||
|
|
e068f49f7d | ||
|
|
20866a7031 | ||
|
|
70e68e0ec6 | ||
|
|
e87d1a63bd | ||
|
|
7cf539c728 | ||
|
|
7b09e9f2c4 | ||
|
|
15e5ac8039 | ||
|
|
48858ad5ca | ||
|
|
2bc5de8635 | ||
|
|
dc5f2e7da6 | ||
|
|
a4921b8ceb | ||
|
|
16591eb3cc | ||
|
|
c3f5413e80 | ||
|
|
aeb810b01e | ||
|
|
25a00cae5b | ||
|
|
620d57f036 | ||
|
|
6fcc290619 | ||
|
|
ed09d0c0a4 | ||
|
|
656390062a | ||
|
|
212e96f39c | ||
|
|
b584a42e3d | ||
|
|
5116214343 | ||
|
|
7986711632 | ||
|
|
1917d750a0 | ||
|
|
7ccd946407 | ||
|
|
5558652709 | ||
|
|
1906cce6fc | ||
|
|
9b11165aec | ||
|
|
22144afa8d | ||
|
|
2b29e4b852 | ||
|
|
6016bcd30e | ||
|
|
1b6ee8f4c7 | ||
|
|
cd49ee0897 | ||
|
|
1e2c7c04b1 | ||
|
|
6cc2a8f8ed | ||
|
|
bfee9a2581 | ||
|
|
f9ff67e948 | ||
|
|
6b05f688ee | ||
|
|
5c06e5297d | ||
|
|
24a356bf71 | ||
|
|
24e063efdc | ||
|
|
ca70fba0bf | ||
|
|
5959c591a0 | ||
|
|
c5f9d0d080 | ||
|
|
75e12b8e66 | ||
|
|
f0576d6775 | ||
|
|
ff08306746 | ||
|
|
bc2e43f3c8 | ||
|
|
039d5a023f | ||
|
|
b09b87321c | ||
|
|
107505e13a | ||
|
|
72d8209548 | ||
|
|
18a48d80a0 | ||
|
|
1b3a03f161 | ||
|
|
229567293c | ||
|
|
a4cb62ac25 | ||
|
|
31a551a60f | ||
|
|
6e85d1b5ba | ||
|
|
3a0cc43ac8 | ||
|
|
be0b9dda31 | ||
|
|
78206f06ec | ||
|
|
2ee9da9e22 | ||
|
|
6eba05613a | ||
|
|
7a03cbf09d | ||
|
|
69b8f9980f | ||
|
|
e93acab852 | ||
|
|
806970349b | ||
|
|
ea019e9a26 | ||
|
|
cc837e2458 | ||
|
|
28034bfa49 | ||
|
|
93f4fa8a15 | ||
|
|
c51b6a893c | ||
|
|
e6c44d166a | ||
|
|
7391533ea5 | ||
|
|
5cc2fc46ec | ||
|
|
3628b61ce0 | ||
|
|
470553bd05 | ||
|
|
4ddd077bfa | ||
|
|
0374d94437 | ||
|
|
00f698eb8b | ||
|
|
938092a213 | ||
|
|
772b70952f | ||
|
|
f9974f856e | ||
|
|
6955d41f2b | ||
|
|
934cf2d1f4 | ||
|
|
08d96ffad0 | ||
|
|
a9b4e26b5c | ||
|
|
c642441beb | ||
|
|
05420e7883 | ||
|
|
258897c265 | ||
|
|
239841787b | ||
|
|
cc63db1dd5 | ||
|
|
2c9cf50746 | ||
|
|
c3fc60d936 | ||
|
|
f72ed36025 | ||
|
|
78d777ca15 | ||
|
|
a68ebf8e37 | ||
|
|
804709706c | ||
|
|
c56bc3d81c | ||
|
|
4b07476848 | ||
|
|
bdd4646338 | ||
|
|
e73d9e9488 | ||
|
|
28bba8c44f | ||
|
|
8057a192e3 | ||
|
|
9fa1bee575 | ||
|
|
f45c731cd7 | ||
|
|
88936411bc |
@@ -1,5 +1,4 @@
|
||||
Makefile
|
||||
Makefile.in
|
||||
Makefile.config
|
||||
|
||||
# /
|
||||
/aclocal.m4
|
||||
@@ -9,18 +8,8 @@ Makefile.in
|
||||
/nix.spec
|
||||
/stamp-h1
|
||||
/svn-revision
|
||||
/NEWS
|
||||
/libtool
|
||||
|
||||
# /config/
|
||||
/config/config.guess
|
||||
/config/config.sub
|
||||
/config/depcomp
|
||||
/config/install-sh
|
||||
/config/missing
|
||||
/config/mkinstalldirs
|
||||
/config/ltmain.sh
|
||||
|
||||
/corepkgs/config.nix
|
||||
|
||||
# /corepkgs/buildenv/
|
||||
@@ -41,10 +30,7 @@ Makefile.in
|
||||
/doc/manual/*.1
|
||||
/doc/manual/*.5
|
||||
/doc/manual/*.8
|
||||
/doc/manual/images
|
||||
/doc/manual/version.txt
|
||||
/doc/manual/NEWS.html
|
||||
/doc/manual/NEWS.txt
|
||||
|
||||
# /scripts/
|
||||
/scripts/nix-profile.sh
|
||||
@@ -95,13 +81,6 @@ Makefile.in
|
||||
|
||||
# /src/nix-log2xml/
|
||||
/src/nix-log2xml/nix-log2xml
|
||||
/src/nix-log2xml/test*.*
|
||||
/src/nix-log2xml/*.log
|
||||
/src/nix-log2xml/*.xml
|
||||
/src/nix-log2xml/*.html
|
||||
|
||||
# /src/nix-setuid-helper/
|
||||
/src/nix-setuid-helper/nix-setuid-helper
|
||||
|
||||
# /src/nix-store/
|
||||
/src/nix-store/nix-store
|
||||
@@ -109,9 +88,11 @@ Makefile.in
|
||||
# /src/nix-daemon/
|
||||
/src/nix-daemon/nix-daemon
|
||||
|
||||
# /src/download-via-ssh/
|
||||
/src/download-via-ssh/download-via-ssh
|
||||
|
||||
# /tests/
|
||||
/tests/test-tmp
|
||||
/tests/config.nix
|
||||
/tests/common.sh
|
||||
/tests/dummy
|
||||
/tests/result*
|
||||
@@ -124,14 +105,16 @@ Makefile.in
|
||||
/perl/lib/Nix/Config.pm
|
||||
/perl/lib/Nix/Store.cc
|
||||
|
||||
.deps
|
||||
.libs
|
||||
/misc/systemd/nix-daemon.service
|
||||
/misc/systemd/nix-daemon.socket
|
||||
/misc/upstart/nix-daemon.conf
|
||||
|
||||
*.a
|
||||
*.lo
|
||||
*.la
|
||||
*.o
|
||||
*.so
|
||||
*.dep
|
||||
*~
|
||||
*.pc
|
||||
|
||||
# GNU Global
|
||||
GPATH
|
||||
|
||||
@@ -1,8 +0,0 @@
|
||||
The following people contributed to Nix, in alphabetical order:
|
||||
|
||||
Martin Bravenboer
|
||||
Eelco Dolstra
|
||||
Niels Janssen
|
||||
Armijn Hemel
|
||||
Rob Vermaas
|
||||
Eelco Visser
|
||||
@@ -0,0 +1,37 @@
|
||||
makefiles = \
|
||||
local.mk \
|
||||
src/boost/format/local.mk \
|
||||
src/libutil/local.mk \
|
||||
src/libstore/local.mk \
|
||||
src/libmain/local.mk \
|
||||
src/libexpr/local.mk \
|
||||
src/nix-hash/local.mk \
|
||||
src/nix-store/local.mk \
|
||||
src/nix-instantiate/local.mk \
|
||||
src/nix-env/local.mk \
|
||||
src/nix-daemon/local.mk \
|
||||
src/download-via-ssh/local.mk \
|
||||
src/nix-log2xml/local.mk \
|
||||
src/bsdiff-4.3/local.mk \
|
||||
perl/local.mk \
|
||||
scripts/local.mk \
|
||||
corepkgs/local.mk \
|
||||
misc/systemd/local.mk \
|
||||
misc/launchd/local.mk \
|
||||
misc/upstart/local.mk \
|
||||
misc/emacs/local.mk \
|
||||
doc/manual/local.mk \
|
||||
tests/local.mk
|
||||
|
||||
GLOBAL_CXXFLAGS += -std=c++0x -g -Wall
|
||||
|
||||
include Makefile.config
|
||||
|
||||
OPTIMIZE = 1
|
||||
|
||||
ifeq ($(OPTIMIZE), 1)
|
||||
GLOBAL_CFLAGS += -O3
|
||||
GLOBAL_CXXFLAGS += -O3
|
||||
endif
|
||||
|
||||
include mk/lib.mk
|
||||
@@ -1,44 +0,0 @@
|
||||
SUBDIRS = src perl scripts corepkgs doc misc tests
|
||||
EXTRA_DIST = substitute.mk nix.spec nix.spec.in bootstrap.sh \
|
||||
NEWS version misc/systemd/nix-daemon.service
|
||||
|
||||
pkginclude_HEADERS = config.h
|
||||
|
||||
include ./substitute.mk
|
||||
|
||||
nix.spec: nix.spec.in
|
||||
|
||||
install-data-local: init-state
|
||||
$(INSTALL) -d $(DESTDIR)$(sysconfdir)/nix
|
||||
$(INSTALL) -d $(DESTDIR)$(docdir)
|
||||
$(INSTALL_DATA) README $(DESTDIR)$(docdir)/
|
||||
|
||||
if INIT_STATE
|
||||
|
||||
# For setuid operation, you can enable the following:
|
||||
# INIT_FLAGS = -g @NIX_GROUP@ -o @NIX_USER@
|
||||
# GROUP_WRITABLE = -m 775
|
||||
|
||||
init-state:
|
||||
$(INSTALL) $(INIT_FLAGS) -d $(DESTDIR)$(localstatedir)/nix
|
||||
$(INSTALL) $(INIT_FLAGS) -d $(DESTDIR)$(localstatedir)/nix/db
|
||||
$(INSTALL) $(INIT_FLAGS) -d $(DESTDIR)$(localstatedir)/log/nix
|
||||
$(INSTALL) $(INIT_FLAGS) -d $(DESTDIR)$(localstatedir)/log/nix/drvs
|
||||
$(INSTALL) $(INIT_FLAGS) -d $(DESTDIR)$(localstatedir)/nix/profiles
|
||||
$(INSTALL) $(INIT_FLAGS) -d $(DESTDIR)$(localstatedir)/nix/gcroots
|
||||
$(INSTALL) $(INIT_FLAGS) -d $(DESTDIR)$(localstatedir)/nix/temproots
|
||||
ln -sfn $(localstatedir)/nix/profiles $(DESTDIR)$(localstatedir)/nix/gcroots/profiles
|
||||
$(INSTALL) $(INIT_FLAGS) -d $(DESTDIR)$(localstatedir)/nix/userpool
|
||||
-$(INSTALL) $(INIT_FLAGS) -d $(DESTDIR)$(storedir)
|
||||
$(INSTALL) $(INIT_FLAGS) $(GROUP_WRITABLE) -d $(DESTDIR)$(localstatedir)/nix/manifests
|
||||
ln -sfn $(localstatedir)/nix/manifests $(DESTDIR)$(localstatedir)/nix/gcroots/manifests
|
||||
|
||||
else
|
||||
|
||||
init-state:
|
||||
|
||||
endif
|
||||
|
||||
NEWS:
|
||||
$(MAKE) -C doc/manual NEWS.txt
|
||||
cp $(srcdir)/doc/manual/NEWS.txt NEWS
|
||||
@@ -0,0 +1,32 @@
|
||||
BDW_GC_LIBS = @BDW_GC_LIBS@
|
||||
CC = @CC@
|
||||
CFLAGS = @CFLAGS@
|
||||
CXX = @CXX@
|
||||
CXXFLAGS = @CXXFLAGS@
|
||||
HAVE_OPENSSL = @HAVE_OPENSSL@
|
||||
OPENSSL_LIBS = @OPENSSL_LIBS@
|
||||
PACKAGE_NAME = @PACKAGE_NAME@
|
||||
PACKAGE_VERSION = @PACKAGE_VERSION@
|
||||
bash = @bash@
|
||||
bindir = @bindir@
|
||||
bsddiff_compat_include = @bsddiff_compat_include@
|
||||
curl = @curl@
|
||||
datadir = @datadir@
|
||||
datarootdir = @datarootdir@
|
||||
dblatex = @dblatex@
|
||||
docdir = @docdir@
|
||||
exec_prefix = @exec_prefix@
|
||||
includedir = @includedir@
|
||||
libdir = @libdir@
|
||||
libexecdir = @libexecdir@
|
||||
localstatedir = @localstatedir@
|
||||
mandir = @mandir@
|
||||
perl = @perl@
|
||||
perlbindings = @perlbindings@
|
||||
perllibdir = @perllibdir@
|
||||
pkglibdir = $(libdir)/$(PACKAGE_NAME)
|
||||
prefix = @prefix@
|
||||
storedir = @storedir@
|
||||
sysconfdir = @sysconfdir@
|
||||
xmllint = @xmllint@
|
||||
xsltproc = @xsltproc@
|
||||
@@ -1,169 +0,0 @@
|
||||
with import <nix-make/lib>;
|
||||
with pkgs;
|
||||
|
||||
rec {
|
||||
|
||||
bin2c = link {
|
||||
objects = [ (compileC { main = ./src/bin2c/bin2c.c; }) ];
|
||||
programName = "bin2c";
|
||||
};
|
||||
|
||||
bsdiff = link {
|
||||
objects = [ (compileC { main = ./src/bsdiff-4.3/bsdiff.c; buildInputs = [ pkgs.bzip2 ]; }) ];
|
||||
programName = "bsdiff";
|
||||
buildInputs = [ pkgs.bzip2 ];
|
||||
flags = "-lbz2";
|
||||
};
|
||||
|
||||
bspatch = link {
|
||||
objects = [ (compileC { main = ./src/bsdiff-4.3/bspatch.c; buildInputs = [ pkgs.bzip2 ]; }) ];
|
||||
programName = "bspatch";
|
||||
buildInputs = [ pkgs.bzip2 ];
|
||||
flags = "-lbz2";
|
||||
};
|
||||
|
||||
libformat = makeLibrary {
|
||||
objects =
|
||||
map (fn: compileC {
|
||||
main = fn;
|
||||
localIncludePath = [ ./src ];
|
||||
})
|
||||
[ ./src/boost/format/format_implementation.cc
|
||||
./src/boost/format/free_funcs.cc
|
||||
./src/boost/format/parsing.cc
|
||||
];
|
||||
libraryName = "format";
|
||||
};
|
||||
|
||||
libutil = makeLibrary {
|
||||
objects =
|
||||
map (fn: compileC {
|
||||
main = fn;
|
||||
localIncludePath = [ ./src/libutil ./src ./. ];
|
||||
buildInputs = [ pkgs.openssl ];
|
||||
})
|
||||
[ ./src/libutil/util.cc
|
||||
./src/libutil/hash.cc
|
||||
./src/libutil/serialise.cc
|
||||
./src/libutil/archive.cc
|
||||
./src/libutil/xml-writer.cc
|
||||
./src/libutil/immutable.cc
|
||||
];
|
||||
libraryName = "util";
|
||||
};
|
||||
|
||||
libstore = makeLibrary {
|
||||
objects =
|
||||
map (fn: compileC {
|
||||
main = fn;
|
||||
localIncludePath = [ ./src/libstore ./src/libutil ./src ./. ];
|
||||
buildInputs = [ pkgs.sqlite ];
|
||||
cFlags = "-DNIX_STORE_DIR=\"/nix/store\" -DNIX_DATA_DIR=\"/home/eelco/Dev/nix/inst/share\" -DNIX_STATE_DIR=\"/nix/var/nix\" -DNIX_LOG_DIR=\"/foo\" -DNIX_CONF_DIR=\"/foo\" -DNIX_LIBEXEC_DIR=\"/foo\" -DNIX_BIN_DIR=\"/home/eelco/Dev/nix/inst/bin\"";
|
||||
})
|
||||
[ ./src/libstore/store-api.cc
|
||||
./src/libstore/local-store.cc
|
||||
./src/libstore/remote-store.cc
|
||||
./src/libstore/derivations.cc
|
||||
./src/libstore/build.cc
|
||||
./src/libstore/misc.cc
|
||||
./src/libstore/globals.cc
|
||||
./src/libstore/references.cc
|
||||
./src/libstore/pathlocks.cc
|
||||
./src/libstore/gc.cc
|
||||
./src/libstore/optimise-store.cc
|
||||
];
|
||||
libraryName = "store";
|
||||
};
|
||||
|
||||
libmain = makeLibrary {
|
||||
objects =
|
||||
map (fn: compileC {
|
||||
main = fn;
|
||||
localIncludePath = [ ./src/libmain ./src/libstore ./src/libutil ./src ./. ];
|
||||
})
|
||||
[ ./src/libmain/shared.cc ];
|
||||
libraryName = "main";
|
||||
};
|
||||
|
||||
nix_hash = link {
|
||||
objects =
|
||||
map (fn: compileC {
|
||||
main = fn;
|
||||
localIncludePath = [ ./src/nix-hash ./src/libmain ./src/libstore ./src/libutil ./src ./. ];
|
||||
})
|
||||
[ ./src/nix-hash/nix-hash.cc
|
||||
];
|
||||
libraries = [ libformat libutil libstore libmain ];
|
||||
buildInputs = [ pkgs.openssl pkgs.sqlite ];
|
||||
flags = "-lssl -lsqlite3 -lstdc++";
|
||||
programName = "nix-hash";
|
||||
};
|
||||
|
||||
nix_store = link {
|
||||
objects =
|
||||
map (fn: compileC {
|
||||
main = fn;
|
||||
localIncludePath = [ ./src/nix-store ./src/libmain ./src/libstore ./src/libutil ./src ./. ];
|
||||
})
|
||||
[ ./src/nix-store/nix-store.cc
|
||||
./src/nix-store/dotgraph.cc
|
||||
./src/nix-store/xmlgraph.cc
|
||||
];
|
||||
libraries = [ libformat libutil libstore libmain ];
|
||||
buildInputs = [ pkgs.openssl pkgs.sqlite ];
|
||||
flags = "-lssl -lsqlite3 -lstdc++";
|
||||
programName = "nix-store";
|
||||
};
|
||||
|
||||
libexpr = makeLibrary {
|
||||
objects =
|
||||
map (fn: compileC {
|
||||
main = fn;
|
||||
localIncludePath = [ ./src/libexpr ./src/libstore ./src/libutil ./src ./. ];
|
||||
})
|
||||
[ ./src/libexpr/nixexpr.cc
|
||||
./src/libexpr/eval.cc
|
||||
./src/libexpr/primops.cc
|
||||
./src/libexpr/lexer-tab.cc
|
||||
./src/libexpr/parser-tab.cc
|
||||
./src/libexpr/get-drvs.cc
|
||||
./src/libexpr/attr-path.cc
|
||||
./src/libexpr/value-to-xml.cc
|
||||
./src/libexpr/common-opts.cc
|
||||
./src/libexpr/names.cc
|
||||
];
|
||||
libraryName = "expr";
|
||||
};
|
||||
|
||||
nix_instantiate = link {
|
||||
objects =
|
||||
map (fn: compileC {
|
||||
main = fn;
|
||||
localIncludePath = [ ./src/nix-instantiate ./src/libexpr ./src/libmain ./src/libstore ./src/libutil ./src ./. ];
|
||||
})
|
||||
[ ./src/nix-instantiate/nix-instantiate.cc ];
|
||||
libraries = [ libformat libutil libstore libmain libexpr ];
|
||||
buildInputs = [ pkgs.openssl pkgs.sqlite ];
|
||||
flags = "-lssl -lsqlite3 -lstdc++";
|
||||
programName = "nix-instantiate";
|
||||
};
|
||||
|
||||
nix_env = link {
|
||||
objects =
|
||||
map (fn: compileC {
|
||||
main = fn;
|
||||
localIncludePath = [ ./src/nix-env ./src/libexpr ./src/libmain ./src/libstore ./src/libutil ./src ./. ];
|
||||
})
|
||||
[ ./src/nix-env/nix-env.cc
|
||||
./src/nix-env/profiles.cc
|
||||
./src/nix-env/user-env.cc
|
||||
];
|
||||
libraries = [ libformat libutil libstore libmain libexpr ];
|
||||
buildInputs = [ pkgs.openssl pkgs.sqlite ];
|
||||
flags = "-lssl -lsqlite3 -lstdc++";
|
||||
programName = "nix-env";
|
||||
};
|
||||
|
||||
all = [ bsdiff bspatch nix_hash nix_store nix_instantiate nix_env ];
|
||||
|
||||
}
|
||||
@@ -0,0 +1,527 @@
|
||||
#!/bin/sh
|
||||
# install - install a program, script, or datafile
|
||||
|
||||
scriptversion=2011-11-20.07; # UTC
|
||||
|
||||
# This originates from X11R5 (mit/util/scripts/install.sh), which was
|
||||
# later released in X11R6 (xc/config/util/install.sh) with the
|
||||
# following copyright and license.
|
||||
#
|
||||
# Copyright (C) 1994 X Consortium
|
||||
#
|
||||
# Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
# of this software and associated documentation files (the "Software"), to
|
||||
# deal in the Software without restriction, including without limitation the
|
||||
# rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
|
||||
# sell copies of the Software, and to permit persons to whom the Software is
|
||||
# furnished to do so, subject to the following conditions:
|
||||
#
|
||||
# The above copyright notice and this permission notice shall be included in
|
||||
# all copies or substantial portions of the Software.
|
||||
#
|
||||
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
# X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
|
||||
# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNEC-
|
||||
# TION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
||||
#
|
||||
# Except as contained in this notice, the name of the X Consortium shall not
|
||||
# be used in advertising or otherwise to promote the sale, use or other deal-
|
||||
# ings in this Software without prior written authorization from the X Consor-
|
||||
# tium.
|
||||
#
|
||||
#
|
||||
# FSF changes to this file are in the public domain.
|
||||
#
|
||||
# Calling this script install-sh is preferred over install.sh, to prevent
|
||||
# 'make' implicit rules from creating a file called install from it
|
||||
# when there is no Makefile.
|
||||
#
|
||||
# This script is compatible with the BSD install script, but was written
|
||||
# from scratch.
|
||||
|
||||
nl='
|
||||
'
|
||||
IFS=" "" $nl"
|
||||
|
||||
# set DOITPROG to echo to test this script
|
||||
|
||||
# Don't use :- since 4.3BSD and earlier shells don't like it.
|
||||
doit=${DOITPROG-}
|
||||
if test -z "$doit"; then
|
||||
doit_exec=exec
|
||||
else
|
||||
doit_exec=$doit
|
||||
fi
|
||||
|
||||
# Put in absolute file names if you don't have them in your path;
|
||||
# or use environment vars.
|
||||
|
||||
chgrpprog=${CHGRPPROG-chgrp}
|
||||
chmodprog=${CHMODPROG-chmod}
|
||||
chownprog=${CHOWNPROG-chown}
|
||||
cmpprog=${CMPPROG-cmp}
|
||||
cpprog=${CPPROG-cp}
|
||||
mkdirprog=${MKDIRPROG-mkdir}
|
||||
mvprog=${MVPROG-mv}
|
||||
rmprog=${RMPROG-rm}
|
||||
stripprog=${STRIPPROG-strip}
|
||||
|
||||
posix_glob='?'
|
||||
initialize_posix_glob='
|
||||
test "$posix_glob" != "?" || {
|
||||
if (set -f) 2>/dev/null; then
|
||||
posix_glob=
|
||||
else
|
||||
posix_glob=:
|
||||
fi
|
||||
}
|
||||
'
|
||||
|
||||
posix_mkdir=
|
||||
|
||||
# Desired mode of installed file.
|
||||
mode=0755
|
||||
|
||||
chgrpcmd=
|
||||
chmodcmd=$chmodprog
|
||||
chowncmd=
|
||||
mvcmd=$mvprog
|
||||
rmcmd="$rmprog -f"
|
||||
stripcmd=
|
||||
|
||||
src=
|
||||
dst=
|
||||
dir_arg=
|
||||
dst_arg=
|
||||
|
||||
copy_on_change=false
|
||||
no_target_directory=
|
||||
|
||||
usage="\
|
||||
Usage: $0 [OPTION]... [-T] SRCFILE DSTFILE
|
||||
or: $0 [OPTION]... SRCFILES... DIRECTORY
|
||||
or: $0 [OPTION]... -t DIRECTORY SRCFILES...
|
||||
or: $0 [OPTION]... -d DIRECTORIES...
|
||||
|
||||
In the 1st form, copy SRCFILE to DSTFILE.
|
||||
In the 2nd and 3rd, copy all SRCFILES to DIRECTORY.
|
||||
In the 4th, create DIRECTORIES.
|
||||
|
||||
Options:
|
||||
--help display this help and exit.
|
||||
--version display version info and exit.
|
||||
|
||||
-c (ignored)
|
||||
-C install only if different (preserve the last data modification time)
|
||||
-d create directories instead of installing files.
|
||||
-g GROUP $chgrpprog installed files to GROUP.
|
||||
-m MODE $chmodprog installed files to MODE.
|
||||
-o USER $chownprog installed files to USER.
|
||||
-s $stripprog installed files.
|
||||
-t DIRECTORY install into DIRECTORY.
|
||||
-T report an error if DSTFILE is a directory.
|
||||
|
||||
Environment variables override the default commands:
|
||||
CHGRPPROG CHMODPROG CHOWNPROG CMPPROG CPPROG MKDIRPROG MVPROG
|
||||
RMPROG STRIPPROG
|
||||
"
|
||||
|
||||
while test $# -ne 0; do
|
||||
case $1 in
|
||||
-c) ;;
|
||||
|
||||
-C) copy_on_change=true;;
|
||||
|
||||
-d) dir_arg=true;;
|
||||
|
||||
-g) chgrpcmd="$chgrpprog $2"
|
||||
shift;;
|
||||
|
||||
--help) echo "$usage"; exit $?;;
|
||||
|
||||
-m) mode=$2
|
||||
case $mode in
|
||||
*' '* | *' '* | *'
|
||||
'* | *'*'* | *'?'* | *'['*)
|
||||
echo "$0: invalid mode: $mode" >&2
|
||||
exit 1;;
|
||||
esac
|
||||
shift;;
|
||||
|
||||
-o) chowncmd="$chownprog $2"
|
||||
shift;;
|
||||
|
||||
-s) stripcmd=$stripprog;;
|
||||
|
||||
-t) dst_arg=$2
|
||||
# Protect names problematic for 'test' and other utilities.
|
||||
case $dst_arg in
|
||||
-* | [=\(\)!]) dst_arg=./$dst_arg;;
|
||||
esac
|
||||
shift;;
|
||||
|
||||
-T) no_target_directory=true;;
|
||||
|
||||
--version) echo "$0 $scriptversion"; exit $?;;
|
||||
|
||||
--) shift
|
||||
break;;
|
||||
|
||||
-*) echo "$0: invalid option: $1" >&2
|
||||
exit 1;;
|
||||
|
||||
*) break;;
|
||||
esac
|
||||
shift
|
||||
done
|
||||
|
||||
if test $# -ne 0 && test -z "$dir_arg$dst_arg"; then
|
||||
# When -d is used, all remaining arguments are directories to create.
|
||||
# When -t is used, the destination is already specified.
|
||||
# Otherwise, the last argument is the destination. Remove it from $@.
|
||||
for arg
|
||||
do
|
||||
if test -n "$dst_arg"; then
|
||||
# $@ is not empty: it contains at least $arg.
|
||||
set fnord "$@" "$dst_arg"
|
||||
shift # fnord
|
||||
fi
|
||||
shift # arg
|
||||
dst_arg=$arg
|
||||
# Protect names problematic for 'test' and other utilities.
|
||||
case $dst_arg in
|
||||
-* | [=\(\)!]) dst_arg=./$dst_arg;;
|
||||
esac
|
||||
done
|
||||
fi
|
||||
|
||||
if test $# -eq 0; then
|
||||
if test -z "$dir_arg"; then
|
||||
echo "$0: no input file specified." >&2
|
||||
exit 1
|
||||
fi
|
||||
# It's OK to call 'install-sh -d' without argument.
|
||||
# This can happen when creating conditional directories.
|
||||
exit 0
|
||||
fi
|
||||
|
||||
if test -z "$dir_arg"; then
|
||||
do_exit='(exit $ret); exit $ret'
|
||||
trap "ret=129; $do_exit" 1
|
||||
trap "ret=130; $do_exit" 2
|
||||
trap "ret=141; $do_exit" 13
|
||||
trap "ret=143; $do_exit" 15
|
||||
|
||||
# Set umask so as not to create temps with too-generous modes.
|
||||
# However, 'strip' requires both read and write access to temps.
|
||||
case $mode in
|
||||
# Optimize common cases.
|
||||
*644) cp_umask=133;;
|
||||
*755) cp_umask=22;;
|
||||
|
||||
*[0-7])
|
||||
if test -z "$stripcmd"; then
|
||||
u_plus_rw=
|
||||
else
|
||||
u_plus_rw='% 200'
|
||||
fi
|
||||
cp_umask=`expr '(' 777 - $mode % 1000 ')' $u_plus_rw`;;
|
||||
*)
|
||||
if test -z "$stripcmd"; then
|
||||
u_plus_rw=
|
||||
else
|
||||
u_plus_rw=,u+rw
|
||||
fi
|
||||
cp_umask=$mode$u_plus_rw;;
|
||||
esac
|
||||
fi
|
||||
|
||||
for src
|
||||
do
|
||||
# Protect names problematic for 'test' and other utilities.
|
||||
case $src in
|
||||
-* | [=\(\)!]) src=./$src;;
|
||||
esac
|
||||
|
||||
if test -n "$dir_arg"; then
|
||||
dst=$src
|
||||
dstdir=$dst
|
||||
test -d "$dstdir"
|
||||
dstdir_status=$?
|
||||
else
|
||||
|
||||
# Waiting for this to be detected by the "$cpprog $src $dsttmp" command
|
||||
# might cause directories to be created, which would be especially bad
|
||||
# if $src (and thus $dsttmp) contains '*'.
|
||||
if test ! -f "$src" && test ! -d "$src"; then
|
||||
echo "$0: $src does not exist." >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if test -z "$dst_arg"; then
|
||||
echo "$0: no destination specified." >&2
|
||||
exit 1
|
||||
fi
|
||||
dst=$dst_arg
|
||||
|
||||
# If destination is a directory, append the input filename; won't work
|
||||
# if double slashes aren't ignored.
|
||||
if test -d "$dst"; then
|
||||
if test -n "$no_target_directory"; then
|
||||
echo "$0: $dst_arg: Is a directory" >&2
|
||||
exit 1
|
||||
fi
|
||||
dstdir=$dst
|
||||
dst=$dstdir/`basename "$src"`
|
||||
dstdir_status=0
|
||||
else
|
||||
# Prefer dirname, but fall back on a substitute if dirname fails.
|
||||
dstdir=`
|
||||
(dirname "$dst") 2>/dev/null ||
|
||||
expr X"$dst" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
|
||||
X"$dst" : 'X\(//\)[^/]' \| \
|
||||
X"$dst" : 'X\(//\)$' \| \
|
||||
X"$dst" : 'X\(/\)' \| . 2>/dev/null ||
|
||||
echo X"$dst" |
|
||||
sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{
|
||||
s//\1/
|
||||
q
|
||||
}
|
||||
/^X\(\/\/\)[^/].*/{
|
||||
s//\1/
|
||||
q
|
||||
}
|
||||
/^X\(\/\/\)$/{
|
||||
s//\1/
|
||||
q
|
||||
}
|
||||
/^X\(\/\).*/{
|
||||
s//\1/
|
||||
q
|
||||
}
|
||||
s/.*/./; q'
|
||||
`
|
||||
|
||||
test -d "$dstdir"
|
||||
dstdir_status=$?
|
||||
fi
|
||||
fi
|
||||
|
||||
obsolete_mkdir_used=false
|
||||
|
||||
if test $dstdir_status != 0; then
|
||||
case $posix_mkdir in
|
||||
'')
|
||||
# Create intermediate dirs using mode 755 as modified by the umask.
|
||||
# This is like FreeBSD 'install' as of 1997-10-28.
|
||||
umask=`umask`
|
||||
case $stripcmd.$umask in
|
||||
# Optimize common cases.
|
||||
*[2367][2367]) mkdir_umask=$umask;;
|
||||
.*0[02][02] | .[02][02] | .[02]) mkdir_umask=22;;
|
||||
|
||||
*[0-7])
|
||||
mkdir_umask=`expr $umask + 22 \
|
||||
- $umask % 100 % 40 + $umask % 20 \
|
||||
- $umask % 10 % 4 + $umask % 2
|
||||
`;;
|
||||
*) mkdir_umask=$umask,go-w;;
|
||||
esac
|
||||
|
||||
# With -d, create the new directory with the user-specified mode.
|
||||
# Otherwise, rely on $mkdir_umask.
|
||||
if test -n "$dir_arg"; then
|
||||
mkdir_mode=-m$mode
|
||||
else
|
||||
mkdir_mode=
|
||||
fi
|
||||
|
||||
posix_mkdir=false
|
||||
case $umask in
|
||||
*[123567][0-7][0-7])
|
||||
# POSIX mkdir -p sets u+wx bits regardless of umask, which
|
||||
# is incompatible with FreeBSD 'install' when (umask & 300) != 0.
|
||||
;;
|
||||
*)
|
||||
tmpdir=${TMPDIR-/tmp}/ins$RANDOM-$$
|
||||
trap 'ret=$?; rmdir "$tmpdir/d" "$tmpdir" 2>/dev/null; exit $ret' 0
|
||||
|
||||
if (umask $mkdir_umask &&
|
||||
exec $mkdirprog $mkdir_mode -p -- "$tmpdir/d") >/dev/null 2>&1
|
||||
then
|
||||
if test -z "$dir_arg" || {
|
||||
# Check for POSIX incompatibilities with -m.
|
||||
# HP-UX 11.23 and IRIX 6.5 mkdir -m -p sets group- or
|
||||
# other-writable bit of parent directory when it shouldn't.
|
||||
# FreeBSD 6.1 mkdir -m -p sets mode of existing directory.
|
||||
ls_ld_tmpdir=`ls -ld "$tmpdir"`
|
||||
case $ls_ld_tmpdir in
|
||||
d????-?r-*) different_mode=700;;
|
||||
d????-?--*) different_mode=755;;
|
||||
*) false;;
|
||||
esac &&
|
||||
$mkdirprog -m$different_mode -p -- "$tmpdir" && {
|
||||
ls_ld_tmpdir_1=`ls -ld "$tmpdir"`
|
||||
test "$ls_ld_tmpdir" = "$ls_ld_tmpdir_1"
|
||||
}
|
||||
}
|
||||
then posix_mkdir=:
|
||||
fi
|
||||
rmdir "$tmpdir/d" "$tmpdir"
|
||||
else
|
||||
# Remove any dirs left behind by ancient mkdir implementations.
|
||||
rmdir ./$mkdir_mode ./-p ./-- 2>/dev/null
|
||||
fi
|
||||
trap '' 0;;
|
||||
esac;;
|
||||
esac
|
||||
|
||||
if
|
||||
$posix_mkdir && (
|
||||
umask $mkdir_umask &&
|
||||
$doit_exec $mkdirprog $mkdir_mode -p -- "$dstdir"
|
||||
)
|
||||
then :
|
||||
else
|
||||
|
||||
# The umask is ridiculous, or mkdir does not conform to POSIX,
|
||||
# or it failed possibly due to a race condition. Create the
|
||||
# directory the slow way, step by step, checking for races as we go.
|
||||
|
||||
case $dstdir in
|
||||
/*) prefix='/';;
|
||||
[-=\(\)!]*) prefix='./';;
|
||||
*) prefix='';;
|
||||
esac
|
||||
|
||||
eval "$initialize_posix_glob"
|
||||
|
||||
oIFS=$IFS
|
||||
IFS=/
|
||||
$posix_glob set -f
|
||||
set fnord $dstdir
|
||||
shift
|
||||
$posix_glob set +f
|
||||
IFS=$oIFS
|
||||
|
||||
prefixes=
|
||||
|
||||
for d
|
||||
do
|
||||
test X"$d" = X && continue
|
||||
|
||||
prefix=$prefix$d
|
||||
if test -d "$prefix"; then
|
||||
prefixes=
|
||||
else
|
||||
if $posix_mkdir; then
|
||||
(umask=$mkdir_umask &&
|
||||
$doit_exec $mkdirprog $mkdir_mode -p -- "$dstdir") && break
|
||||
# Don't fail if two instances are running concurrently.
|
||||
test -d "$prefix" || exit 1
|
||||
else
|
||||
case $prefix in
|
||||
*\'*) qprefix=`echo "$prefix" | sed "s/'/'\\\\\\\\''/g"`;;
|
||||
*) qprefix=$prefix;;
|
||||
esac
|
||||
prefixes="$prefixes '$qprefix'"
|
||||
fi
|
||||
fi
|
||||
prefix=$prefix/
|
||||
done
|
||||
|
||||
if test -n "$prefixes"; then
|
||||
# Don't fail if two instances are running concurrently.
|
||||
(umask $mkdir_umask &&
|
||||
eval "\$doit_exec \$mkdirprog $prefixes") ||
|
||||
test -d "$dstdir" || exit 1
|
||||
obsolete_mkdir_used=true
|
||||
fi
|
||||
fi
|
||||
fi
|
||||
|
||||
if test -n "$dir_arg"; then
|
||||
{ test -z "$chowncmd" || $doit $chowncmd "$dst"; } &&
|
||||
{ test -z "$chgrpcmd" || $doit $chgrpcmd "$dst"; } &&
|
||||
{ test "$obsolete_mkdir_used$chowncmd$chgrpcmd" = false ||
|
||||
test -z "$chmodcmd" || $doit $chmodcmd $mode "$dst"; } || exit 1
|
||||
else
|
||||
|
||||
# Make a couple of temp file names in the proper directory.
|
||||
dsttmp=$dstdir/_inst.$$_
|
||||
rmtmp=$dstdir/_rm.$$_
|
||||
|
||||
# Trap to clean up those temp files at exit.
|
||||
trap 'ret=$?; rm -f "$dsttmp" "$rmtmp" && exit $ret' 0
|
||||
|
||||
# Copy the file name to the temp name.
|
||||
(umask $cp_umask && $doit_exec $cpprog "$src" "$dsttmp") &&
|
||||
|
||||
# and set any options; do chmod last to preserve setuid bits.
|
||||
#
|
||||
# If any of these fail, we abort the whole thing. If we want to
|
||||
# ignore errors from any of these, just make sure not to ignore
|
||||
# errors from the above "$doit $cpprog $src $dsttmp" command.
|
||||
#
|
||||
{ test -z "$chowncmd" || $doit $chowncmd "$dsttmp"; } &&
|
||||
{ test -z "$chgrpcmd" || $doit $chgrpcmd "$dsttmp"; } &&
|
||||
{ test -z "$stripcmd" || $doit $stripcmd "$dsttmp"; } &&
|
||||
{ test -z "$chmodcmd" || $doit $chmodcmd $mode "$dsttmp"; } &&
|
||||
|
||||
# If -C, don't bother to copy if it wouldn't change the file.
|
||||
if $copy_on_change &&
|
||||
old=`LC_ALL=C ls -dlL "$dst" 2>/dev/null` &&
|
||||
new=`LC_ALL=C ls -dlL "$dsttmp" 2>/dev/null` &&
|
||||
|
||||
eval "$initialize_posix_glob" &&
|
||||
$posix_glob set -f &&
|
||||
set X $old && old=:$2:$4:$5:$6 &&
|
||||
set X $new && new=:$2:$4:$5:$6 &&
|
||||
$posix_glob set +f &&
|
||||
|
||||
test "$old" = "$new" &&
|
||||
$cmpprog "$dst" "$dsttmp" >/dev/null 2>&1
|
||||
then
|
||||
rm -f "$dsttmp"
|
||||
else
|
||||
# Rename the file to the real destination.
|
||||
$doit $mvcmd -f "$dsttmp" "$dst" 2>/dev/null ||
|
||||
|
||||
# The rename failed, perhaps because mv can't rename something else
|
||||
# to itself, or perhaps because mv is so ancient that it does not
|
||||
# support -f.
|
||||
{
|
||||
# Now remove or move aside any old file at destination location.
|
||||
# We try this two ways since rm can't unlink itself on some
|
||||
# systems and the destination file might be busy for other
|
||||
# reasons. In this case, the final cleanup might fail but the new
|
||||
# file should still install successfully.
|
||||
{
|
||||
test ! -f "$dst" ||
|
||||
$doit $rmcmd -f "$dst" 2>/dev/null ||
|
||||
{ $doit $mvcmd -f "$dst" "$rmtmp" 2>/dev/null &&
|
||||
{ $doit $rmcmd -f "$rmtmp" 2>/dev/null; :; }
|
||||
} ||
|
||||
{ echo "$0: cannot unlink or rename $dst" >&2
|
||||
(exit 1); exit 1
|
||||
}
|
||||
} &&
|
||||
|
||||
# Now rename the file to the real destination.
|
||||
$doit $mvcmd "$dsttmp" "$dst"
|
||||
}
|
||||
fi || exit 1
|
||||
|
||||
trap '' 0
|
||||
fi
|
||||
done
|
||||
|
||||
# Local variables:
|
||||
# eval: (add-hook 'write-file-hooks 'time-stamp)
|
||||
# time-stamp-start: "scriptversion="
|
||||
# time-stamp-format: "%:y-%02m-%02d.%02H"
|
||||
# time-stamp-time-zone: "UTC"
|
||||
# time-stamp-end: "; # UTC"
|
||||
# End:
|
||||
@@ -1,9 +1,6 @@
|
||||
AC_INIT(nix, m4_esyscmd([echo -n $(cat ./version)$VERSION_SUFFIX]))
|
||||
AC_INIT(nix, m4_esyscmd([bash -c "echo -n $(cat ./version)$VERSION_SUFFIX"]))
|
||||
AC_CONFIG_SRCDIR(README)
|
||||
AC_CONFIG_AUX_DIR(config)
|
||||
AM_INIT_AUTOMAKE([dist-bzip2 foreign])
|
||||
|
||||
AC_DEFINE_UNQUOTED(NIX_VERSION, ["$VERSION"], [Nix version.])
|
||||
|
||||
AC_PROG_SED
|
||||
|
||||
@@ -50,17 +47,6 @@ AC_DEFINE_UNQUOTED(SYSTEM, ["$system"], [platform identifier (`cpu-os')])
|
||||
test "$localstatedir" = '${prefix}/var' && localstatedir=/nix/var
|
||||
|
||||
|
||||
# Windows-specific stuff. On Cygwin, dynamically linking against the
|
||||
# ATerm DLL works, except that it requires the ATerm "lib" directory
|
||||
# to be in $PATH, as Windows doesn't have anything like an RPATH
|
||||
# embedded in executable. Since this is kind of annoying, we use
|
||||
# static libraries for now.
|
||||
if test "$sys_name" = "cygwin"; then
|
||||
AC_DISABLE_SHARED
|
||||
AC_ENABLE_STATIC
|
||||
fi
|
||||
|
||||
|
||||
# Solaris-specific stuff.
|
||||
if test "$sys_name" = sunos; then
|
||||
# Solaris requires -lsocket -lnsl for network functions
|
||||
@@ -68,24 +54,11 @@ if test "$sys_name" = sunos; then
|
||||
fi
|
||||
|
||||
|
||||
CFLAGS=
|
||||
CXXFLAGS=
|
||||
AC_PROG_CC
|
||||
AC_PROG_CXX
|
||||
|
||||
# To build programs to be run in the build machine.
|
||||
if test "$CC_FOR_BUILD" = ""; then
|
||||
if test "$cross_compiling" = "yes"; then
|
||||
AC_CHECK_PROGS(CC_FOR_BUILD, gcc cc)
|
||||
else
|
||||
CC_FOR_BUILD="$CC"
|
||||
fi
|
||||
fi
|
||||
AC_SUBST([CC_FOR_BUILD])
|
||||
|
||||
# We are going to use libtool.
|
||||
AC_DISABLE_STATIC
|
||||
AC_ENABLE_SHARED
|
||||
AC_PROG_LIBTOOL
|
||||
|
||||
|
||||
# Use 64-bit file system calls so that we can support files > 2 GiB.
|
||||
AC_SYS_LARGEFILE
|
||||
@@ -106,6 +79,7 @@ AC_LANG_POP(C++)
|
||||
# Check for chroot support (requires chroot() and bind mounts).
|
||||
AC_CHECK_FUNCS([chroot])
|
||||
AC_CHECK_FUNCS([unshare])
|
||||
AC_CHECK_FUNCS([statvfs])
|
||||
AC_CHECK_HEADERS([sched.h])
|
||||
AC_CHECK_HEADERS([sys/param.h])
|
||||
AC_CHECK_HEADERS([sys/mount.h], [], [],
|
||||
@@ -115,15 +89,15 @@ AC_CHECK_HEADERS([sys/mount.h], [], [],
|
||||
])
|
||||
|
||||
|
||||
# Check for vfork.
|
||||
#AC_FUNC_FORK()
|
||||
|
||||
|
||||
# Check for lutimes, optionally used for changing the mtime of
|
||||
# symlinks.
|
||||
AC_CHECK_FUNCS([lutimes])
|
||||
|
||||
|
||||
# Check for sched_setaffinity.
|
||||
AC_CHECK_FUNCS([sched_setaffinity])
|
||||
|
||||
|
||||
# Check whether the store optimiser can optimise symlinks.
|
||||
AC_MSG_CHECKING([whether it is possible to create a link to a symlink])
|
||||
ln -s bla tmp_link
|
||||
@@ -147,21 +121,10 @@ AC_CHECK_HEADER([err.h], [], [bsddiff_compat_include="-Icompat-include"])
|
||||
AC_SUBST([bsddiff_compat_include])
|
||||
|
||||
|
||||
# Check whether we have the personality() syscall, which allows us to
|
||||
# do i686-linux builds on x86_64-linux machines.
|
||||
AC_CHECK_HEADERS([sys/personality.h])
|
||||
|
||||
|
||||
# Check for <linux/fs.h> (for immutable file support).
|
||||
AC_CHECK_HEADERS([linux/fs.h])
|
||||
|
||||
|
||||
# Check for tr1/unordered_set.
|
||||
AC_LANG_PUSH(C++)
|
||||
AC_CHECK_HEADERS([tr1/unordered_set])
|
||||
AC_LANG_POP(C++)
|
||||
|
||||
|
||||
AC_DEFUN([NEED_PROG],
|
||||
[
|
||||
AC_PATH_PROG($1, $2)
|
||||
@@ -175,17 +138,16 @@ NEED_PROG(bash, bash)
|
||||
NEED_PROG(patch, patch)
|
||||
AC_PATH_PROG(xmllint, xmllint, false)
|
||||
AC_PATH_PROG(xsltproc, xsltproc, false)
|
||||
AC_PATH_PROG(w3m, w3m, false)
|
||||
AC_PATH_PROG(flex, flex, false)
|
||||
AC_PATH_PROG(bison, bison, false)
|
||||
NEED_PROG(perl, perl)
|
||||
NEED_PROG(sed, sed)
|
||||
NEED_PROG(tar, tar)
|
||||
NEED_PROG(bzip2, bzip2)
|
||||
NEED_PROG(gzip, gzip)
|
||||
NEED_PROG(xz, xz)
|
||||
AC_PATH_PROG(dot, dot)
|
||||
AC_PATH_PROG(dblatex, dblatex)
|
||||
AC_PATH_PROG(gzip, gzip)
|
||||
AC_PATH_PROG(pv, pv, pv)
|
||||
|
||||
|
||||
@@ -202,7 +164,7 @@ AC_MSG_RESULT(yes)
|
||||
AC_MSG_CHECKING([for the Perl installation prefix])
|
||||
perlversion=$($perl -e 'use Config; print $Config{version};')
|
||||
perlarchname=$($perl -e 'use Config; print $Config{archname};')
|
||||
AC_SUBST(perllibdir, [$\(libdir\)/perl5/site_perl/$perlversion/$perlarchname])
|
||||
AC_SUBST(perllibdir, [${libdir}/perl5/site_perl/$perlversion/$perlarchname])
|
||||
AC_MSG_RESULT($perllibdir)
|
||||
|
||||
|
||||
@@ -214,23 +176,6 @@ AC_ARG_WITH(coreutils-bin, AC_HELP_STRING([--with-coreutils-bin=PATH],
|
||||
AC_SUBST(coreutils)
|
||||
|
||||
|
||||
AC_ARG_WITH(docbook-rng, AC_HELP_STRING([--with-docbook-rng=PATH],
|
||||
[path of the DocBook RelaxNG schema]),
|
||||
docbookrng=$withval, docbookrng=/docbook-rng-missing)
|
||||
AC_SUBST(docbookrng)
|
||||
|
||||
AC_ARG_WITH(docbook-xsl, AC_HELP_STRING([--with-docbook-xsl=PATH],
|
||||
[path of the DocBook XSL stylesheets]),
|
||||
docbookxsl=$withval, docbookxsl=/docbook-xsl-missing)
|
||||
AC_SUBST(docbookxsl)
|
||||
|
||||
|
||||
AC_ARG_WITH(xml-flags, AC_HELP_STRING([--with-xml-flags=FLAGS],
|
||||
[extra flags to be passed to xmllint and xsltproc]),
|
||||
xmlflags=$withval, xmlflags=)
|
||||
AC_SUBST(xmlflags)
|
||||
|
||||
|
||||
AC_ARG_WITH(store-dir, AC_HELP_STRING([--with-store-dir=PATH],
|
||||
[path of the Nix store (defaults to /nix/store)]),
|
||||
storedir=$withval, storedir='/nix/store')
|
||||
@@ -238,15 +183,15 @@ AC_SUBST(storedir)
|
||||
|
||||
|
||||
# Look for OpenSSL, an optional dependency.
|
||||
AC_PATH_PROG(openssl_prog, openssl, openssl) # if not found, call openssl in $PATH
|
||||
AC_SUBST(openssl_prog)
|
||||
AC_DEFINE_UNQUOTED(OPENSSL_PATH, ["$openssl_prog"], [Path of the OpenSSL binary])
|
||||
AC_PATH_PROG(openssl, openssl, openssl) # if not found, call openssl in $PATH
|
||||
AC_SUBST(openssl)
|
||||
AC_DEFINE_UNQUOTED(OPENSSL_PATH, ["$openssl"], [Path of the OpenSSL binary])
|
||||
|
||||
PKG_CHECK_MODULES([OPENSSL], [libcrypto],
|
||||
[AC_DEFINE([HAVE_OPENSSL], [1], [Whether to use OpenSSL.])
|
||||
CXXFLAGS="$OPENSSL_CFLAGS $CXXFLAGS"
|
||||
have_openssl=1], [true])
|
||||
AM_CONDITIONAL(HAVE_OPENSSL, test "$have_openssl" = 1)
|
||||
have_openssl=1], [have_openssl=])
|
||||
AC_SUBST(HAVE_OPENSSL, [$have_openssl])
|
||||
|
||||
|
||||
# Look for libbz2, a required dependency.
|
||||
@@ -312,7 +257,6 @@ if test "$enable_shared" = no; then
|
||||
# Perl bindings require shared libraries.
|
||||
perlbindings=no
|
||||
fi
|
||||
AM_CONDITIONAL(PERL_BINDINGS, test "$perlbindings" = "yes")
|
||||
AC_SUBST(perlbindings)
|
||||
AC_MSG_RESULT($perlbindings)
|
||||
|
||||
@@ -320,7 +264,7 @@ AC_MSG_RESULT($perlbindings)
|
||||
AC_ARG_ENABLE(init-state, AC_HELP_STRING([--disable-init-state],
|
||||
[do not initialise DB etc. in `make install']),
|
||||
init_state=$enableval, init_state=yes)
|
||||
AM_CONDITIONAL(INIT_STATE, test "$init_state" = "yes")
|
||||
#AM_CONDITIONAL(INIT_STATE, test "$init_state" = "yes")
|
||||
|
||||
|
||||
# Setuid installations.
|
||||
@@ -354,30 +298,17 @@ fi
|
||||
AC_SUBST(tarFlags)
|
||||
|
||||
|
||||
AM_CONFIG_HEADER([config.h])
|
||||
AC_CONFIG_FILES([Makefile
|
||||
src/Makefile
|
||||
src/boost/Makefile
|
||||
src/boost/format/Makefile
|
||||
src/libutil/Makefile
|
||||
src/libstore/Makefile
|
||||
src/libmain/Makefile
|
||||
src/nix-store/Makefile
|
||||
src/nix-hash/Makefile
|
||||
src/libexpr/Makefile
|
||||
src/nix-instantiate/Makefile
|
||||
src/nix-env/Makefile
|
||||
src/nix-daemon/Makefile
|
||||
src/nix-setuid-helper/Makefile
|
||||
src/nix-log2xml/Makefile
|
||||
src/bsdiff-4.3/Makefile
|
||||
perl/Makefile
|
||||
scripts/Makefile
|
||||
corepkgs/Makefile
|
||||
doc/Makefile
|
||||
doc/manual/Makefile
|
||||
misc/Makefile
|
||||
misc/emacs/Makefile
|
||||
tests/Makefile
|
||||
])
|
||||
# Expand all variables in config.status.
|
||||
test "$prefix" = NONE && prefix=$ac_default_prefix
|
||||
test "$exec_prefix" = NONE && exec_prefix='${prefix}'
|
||||
for name in $ac_subst_vars; do
|
||||
declare $name="$(eval echo "${!name}")"
|
||||
declare $name="$(eval echo "${!name}")"
|
||||
declare $name="$(eval echo "${!name}")"
|
||||
done
|
||||
|
||||
rm -f Makefile.config
|
||||
|
||||
AC_CONFIG_HEADER([config.h])
|
||||
AC_CONFIG_FILES([])
|
||||
AC_OUTPUT
|
||||
|
||||
@@ -1,12 +0,0 @@
|
||||
all-local: config.nix
|
||||
|
||||
files = nar.nix buildenv.nix buildenv.pl unpack-channel.nix derivation.nix fetchurl.nix \
|
||||
imported-drv-to-derivation.nix
|
||||
|
||||
install-exec-local:
|
||||
$(INSTALL) -d $(DESTDIR)$(datadir)/nix/corepkgs
|
||||
$(INSTALL_DATA) config.nix $(files) $(DESTDIR)$(datadir)/nix/corepkgs
|
||||
|
||||
include ../substitute.mk
|
||||
|
||||
EXTRA_DIST = config.nix.in $(files)
|
||||
@@ -1,6 +1,7 @@
|
||||
use strict;
|
||||
use Cwd;
|
||||
use IO::Handle;
|
||||
use utf8;
|
||||
|
||||
STDOUT->autoflush(1);
|
||||
|
||||
@@ -36,9 +37,6 @@ sub createLinks {
|
||||
if ($srcFile =~ /\/propagated-build-inputs$/ ||
|
||||
$srcFile =~ /\/nix-support$/ ||
|
||||
$srcFile =~ /\/perllocal.pod$/ ||
|
||||
$srcFile =~ /\/easy-install.pth$/ ||
|
||||
$srcFile =~ /\/site.py$/ ||
|
||||
$srcFile =~ /\/site.pyc$/ ||
|
||||
$srcFile =~ /\/info\/dir$/ ||
|
||||
$srcFile =~ /\/log$/)
|
||||
{
|
||||
@@ -56,18 +54,18 @@ sub createLinks {
|
||||
elsif (-l _) {
|
||||
my $target = readlink $dstFile or die;
|
||||
if (!-d $target) {
|
||||
die "collission between directory `$srcFile' and non-directory `$target'";
|
||||
die "collision between directory ‘$srcFile’ and non-directory ‘$target’";
|
||||
}
|
||||
unlink $dstFile or die "error unlinking `$dstFile': $!";
|
||||
unlink $dstFile or die "error unlinking ‘$dstFile’: $!";
|
||||
mkdir $dstFile, 0755 ||
|
||||
die "error creating directory `$dstFile': $!";
|
||||
die "error creating directory ‘$dstFile’: $!";
|
||||
createLinks($target, $dstFile, $priorities{$dstFile});
|
||||
createLinks($srcFile, $dstFile, $priority);
|
||||
}
|
||||
|
||||
else {
|
||||
symlink($srcFile, $dstFile) ||
|
||||
die "error creating link `$dstFile': $!";
|
||||
die "error creating link ‘$dstFile’: $!";
|
||||
$priorities{$dstFile} = $priority;
|
||||
$symlinks++;
|
||||
}
|
||||
@@ -78,17 +76,16 @@ sub createLinks {
|
||||
if (-l $dstFile) {
|
||||
my $target = readlink $dstFile;
|
||||
my $prevPriority = $priorities{$dstFile};
|
||||
die ( "collission between `$srcFile' and `$target'; "
|
||||
. "use `nix-env --set-flag "
|
||||
. "priority NUMBER PKGNAME' to change the priority of "
|
||||
. "one of the conflicting packages\n" )
|
||||
die("collision between ‘$srcFile’ and ‘$target’; " .
|
||||
"use ‘nix-env --set-flag priority NUMBER PKGNAME’ " .
|
||||
"to change the priority of one of the conflicting packages\n")
|
||||
if $prevPriority == $priority;
|
||||
next if $prevPriority < $priority;
|
||||
unlink $dstFile or die;
|
||||
}
|
||||
|
||||
symlink($srcFile, $dstFile) ||
|
||||
die "error creating link `$dstFile': $!";
|
||||
die "error creating link ‘$dstFile’: $!";
|
||||
$priorities{$dstFile} = $priority;
|
||||
$symlinks++;
|
||||
}
|
||||
|
||||
@@ -4,9 +4,10 @@ let
|
||||
if val != "" then val else def;
|
||||
in {
|
||||
perl = "@perl@";
|
||||
shell = "@shell@";
|
||||
shell = "@bash@";
|
||||
coreutils = "@coreutils@";
|
||||
bzip2 = "@bzip2@";
|
||||
gzip = "@gzip@";
|
||||
xz = "@xz@";
|
||||
tar = "@tar@";
|
||||
tarFlags = "@tarFlags@";
|
||||
|
||||
@@ -34,4 +34,12 @@ derivation {
|
||||
|
||||
# Don't build in a chroot because Nix's dependencies may not be there.
|
||||
__noChroot = true;
|
||||
|
||||
impureEnvVars = [
|
||||
# We borrow these environment variables from the caller to allow
|
||||
# easy proxy configuration. This is impure, but a fixed-output
|
||||
# derivation like fetchurl is allowed to do so since its result is
|
||||
# by definition pure.
|
||||
"http_proxy" "https_proxy" "ftp_proxy" "all_proxy" "no_proxy"
|
||||
];
|
||||
}
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
corepkgs_FILES = nar.nix buildenv.nix buildenv.pl unpack-channel.nix derivation.nix fetchurl.nix imported-drv-to-derivation.nix
|
||||
|
||||
$(foreach file,config.nix $(corepkgs_FILES),$(eval $(call install-data-in,$(d)/$(file),$(datadir)/nix/corepkgs)))
|
||||
|
||||
template-files += $(d)/config.nix
|
||||
@@ -6,25 +6,28 @@ let
|
||||
''
|
||||
export PATH=${nixBinDir}:${coreutils}
|
||||
|
||||
if [ $compressionType = "xz" ]; then
|
||||
ext=xz
|
||||
compressor="${xz} -9"
|
||||
if [ $compressionType = xz ]; then
|
||||
ext=.xz
|
||||
compressor="| ${xz} -7"
|
||||
elif [ $compressionType = bzip2 ]; then
|
||||
ext=.bz2
|
||||
compressor="| ${bzip2}"
|
||||
else
|
||||
ext=bz2
|
||||
compressor="${bzip2}"
|
||||
ext=
|
||||
compressor=
|
||||
fi
|
||||
|
||||
echo "packing ‘$storePath’..."
|
||||
mkdir $out
|
||||
dst=$out/tmp.nar.$ext
|
||||
dst=$out/tmp.nar$ext
|
||||
|
||||
set -o pipefail
|
||||
nix-store --dump "$storePath" | $compressor > $dst
|
||||
eval "nix-store --dump \"$storePath\" $compressor > $dst"
|
||||
|
||||
hash=$(nix-hash --flat --type $hashAlgo --base32 $dst)
|
||||
echo -n $hash > $out/nar-compressed-hash
|
||||
|
||||
mv $dst $out/$hash.nar.$ext
|
||||
mv $dst $out/$hash.nar$ext
|
||||
'';
|
||||
|
||||
in
|
||||
@@ -40,4 +43,7 @@ derivation {
|
||||
|
||||
# Don't build in a chroot because Nix's dependencies may not be there.
|
||||
__noChroot = true;
|
||||
|
||||
# Remote machines may not have ${nixBinDir} or ${coreutils} in the same prefixes
|
||||
preferLocalBuild = true;
|
||||
}
|
||||
|
||||
@@ -6,9 +6,12 @@ let
|
||||
''
|
||||
mkdir $out
|
||||
cd $out
|
||||
pat="\.xz\$"
|
||||
if [[ "$src" =~ $pat ]]; then
|
||||
xzpat="\.xz\$"
|
||||
gzpat="\.gz\$"
|
||||
if [[ "$src" =~ $xzpat ]]; then
|
||||
${xz} -d < $src | ${tar} xf - ${tarFlags}
|
||||
elif [[ "$src" =~ $gzpat ]]; then
|
||||
${gzip} -d < $src | ${tar} xf - ${tarFlags}
|
||||
else
|
||||
${bzip2} -d < $src | ${tar} xf - ${tarFlags}
|
||||
fi
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
#!/usr/bin/env bash
|
||||
if [ -e tests/test-tmp ]; then
|
||||
chmod -R u+w tests/test-tmp
|
||||
rm -rf tests/test-tmp
|
||||
fi
|
||||
|
||||
s=$(type -p nix-shell)
|
||||
exec $s release.nix -A tarball --command "
|
||||
unset http_proxy
|
||||
export NIX_REMOTE=$NIX_REMOTE
|
||||
export NIX_PATH='$NIX_PATH'
|
||||
export NIX_BUILD_SHELL=$(type -p bash)
|
||||
export c=\$configureFlags
|
||||
exec $s release.nix -A build.$(if [ $(uname -s) = Darwin ]; then echo x86_64-darwin; else echo x86_64-linux; fi) --exclude tarball --command '
|
||||
configureFlags+=\" \$c --prefix=$(pwd)/inst --sysconfdir=$(pwd)/inst/etc\"
|
||||
return
|
||||
'" \
|
||||
"$@"
|
||||
@@ -1 +0,0 @@
|
||||
SUBDIRS = manual
|
||||
@@ -1,117 +0,0 @@
|
||||
XMLLINT = $(xmllint) --nonet $(xmlflags)
|
||||
XSLTPROC = $(xsltproc) --nonet $(xmlflags) \
|
||||
--param section.autolabel 1 \
|
||||
--param section.label.includes.component.label 1 \
|
||||
--param html.stylesheet \'style.css\' \
|
||||
--param xref.with.number.and.title 1 \
|
||||
--param toc.section.depth 3 \
|
||||
--param admon.style \'\' \
|
||||
--param callout.graphics.extension \'.gif\' \
|
||||
--param contrib.inline.enabled 0
|
||||
|
||||
dblatex_opts = \
|
||||
-P doc.collab.show=0 \
|
||||
-P latex.output.revhistory=0
|
||||
|
||||
# Note: we use GIF for now, since the PNGs shipped with Docbook aren't
|
||||
# transparent.
|
||||
|
||||
man1_MANS = nix-env.1 nix-build.1 nix-store.1 nix-instantiate.1 \
|
||||
nix-collect-garbage.1 nix-push.1 nix-pull.1 \
|
||||
nix-prefetch-url.1 nix-channel.1 \
|
||||
nix-install-package.1 nix-hash.1 nix-copy-closure.1
|
||||
|
||||
man5_MANS = nix.conf.5
|
||||
|
||||
man8_MANS = nix-daemon.8
|
||||
|
||||
FIGURES = figures/user-environments.png
|
||||
|
||||
MANUAL_SRCS = manual.xml introduction.xml installation.xml \
|
||||
package-management.xml writing-nix-expressions.xml builtins.xml \
|
||||
build-farm.xml \
|
||||
$(man1_MANS:.1=.xml) $(man8_MANS:.8=.xml) \
|
||||
troubleshooting.xml bugs.xml opt-common.xml opt-common-syn.xml opt-inst-syn.xml \
|
||||
env-common.xml quick-start.xml nix-lang-ref.xml glossary.xml \
|
||||
conf-file.xml release-notes.xml \
|
||||
style.css images
|
||||
|
||||
# Do XInclude processing.
|
||||
manual.xmli: $(MANUAL_SRCS) version.txt
|
||||
$(XMLLINT) --xinclude $< -o $@.tmp
|
||||
mv $@.tmp $@
|
||||
|
||||
# Note: RelaxNG validation requires xmllint >= 2.7.4.
|
||||
manual.is-valid: manual.xmli
|
||||
$(XSLTPROC) --novalid --stringparam profile.condition manual \
|
||||
$(docbookxsl)/profiling/profile.xsl $< 2> /dev/null | \
|
||||
$(XMLLINT) --noout --relaxng $(docbookrng)/docbook.rng -
|
||||
touch $@
|
||||
|
||||
version.txt:
|
||||
echo -n $(VERSION) > version.txt
|
||||
|
||||
man $(MANS): manual.is-valid
|
||||
$(XSLTPROC) --stringparam profile.condition manpage \
|
||||
$(docbookxsl)/profiling/profile.xsl manual.xmli 2> /dev/null | \
|
||||
$(XSLTPROC) $(docbookxsl)/manpages/docbook.xsl -
|
||||
|
||||
manual.html: $(MANUAL_SRCS) manual.is-valid images
|
||||
$(XSLTPROC) --xinclude --stringparam profile.condition manual \
|
||||
$(docbookxsl)/profiling/profile.xsl manual.xml | \
|
||||
$(XSLTPROC) --output manual.html $(docbookxsl)/html/docbook.xsl -
|
||||
|
||||
manual.pdf: $(MANUAL_SRCS) manual.is-valid images
|
||||
if test "$(dblatex)" != ""; then \
|
||||
$(XSLTPROC) --xinclude --stringparam profile.condition manual \
|
||||
$(docbookxsl)/profiling/profile.xsl manual.xml | \
|
||||
$(dblatex) -o manual.pdf $(dblatex_opts) -; \
|
||||
else \
|
||||
echo "Please install dblatex and rerun configure."; \
|
||||
exit 1; \
|
||||
fi
|
||||
|
||||
|
||||
NEWS_OPTS = \
|
||||
--stringparam generate.toc "article nop" \
|
||||
--stringparam section.autolabel.max.depth 0 \
|
||||
--stringparam header.rule 0
|
||||
|
||||
NEWS.html: release-notes.xml
|
||||
$(XSLTPROC) --xinclude --output $@ $(NEWS_OPTS) \
|
||||
$(docbookxsl)/html/docbook.xsl release-notes.xml
|
||||
|
||||
NEWS.txt: release-notes.xml
|
||||
$(XSLTPROC) --xinclude quote-literals.xsl release-notes.xml | \
|
||||
$(XSLTPROC) --output $@.tmp.html $(NEWS_OPTS) \
|
||||
$(docbookxsl)/html/docbook.xsl -
|
||||
LANG=en_US $(w3m) -dump $@.tmp.html > $@
|
||||
rm $@.tmp.html
|
||||
|
||||
|
||||
all-local: manual.html NEWS.html NEWS.txt
|
||||
|
||||
install-data-local: manual.html
|
||||
$(INSTALL) -d $(DESTDIR)$(docdir)/manual
|
||||
$(INSTALL_DATA) manual.html $(DESTDIR)$(docdir)/manual
|
||||
ln -sf manual.html $(DESTDIR)$(docdir)/manual/index.html
|
||||
$(INSTALL_DATA) style.css $(DESTDIR)$(docdir)/manual
|
||||
cp -r images $(DESTDIR)$(docdir)/manual/images
|
||||
$(INSTALL) -d $(DESTDIR)$(docdir)/manual/figures
|
||||
$(INSTALL_DATA) $(FIGURES) $(DESTDIR)$(docdir)/manual/figures
|
||||
$(INSTALL) -d $(DESTDIR)$(docdir)/release-notes
|
||||
$(INSTALL_DATA) NEWS.html $(DESTDIR)$(docdir)/release-notes/index.html
|
||||
$(INSTALL_DATA) style.css $(DESTDIR)$(docdir)/release-notes/
|
||||
|
||||
images:
|
||||
mkdir images
|
||||
# cp $(docbookxsl)/images/*.gif images
|
||||
mkdir images/callouts
|
||||
cp $(docbookxsl)/images/callouts/*.gif images/callouts
|
||||
chmod -R +w images
|
||||
|
||||
KEEP = manual.html manual.xmli manual.is-valid version.txt $(MANS) NEWS.html NEWS.txt
|
||||
|
||||
EXTRA_DIST = $(MANUAL_SRCS) $(FIGURES) $(KEEP)
|
||||
|
||||
DISTCLEANFILES = $(KEEP)
|
||||
@@ -0,0 +1,10 @@
|
||||
<part xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0">
|
||||
|
||||
<title>Advanced Topics</title>
|
||||
|
||||
<xi:include href="distributed-builds.xml" />
|
||||
|
||||
</part>
|
||||
@@ -1,10 +1,12 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id='chap-distributed-builds'>
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='chap-distributed-builds'>
|
||||
|
||||
<title>Setting Up Distributed Builds</title>
|
||||
<title>Distributed Builds</title>
|
||||
|
||||
<para>Nix supports distributed builds: a local Nix installation can
|
||||
<para>Nix supports distributed builds, where a local Nix installation can
|
||||
forward Nix builds to other machines over the network. This allows
|
||||
multiple builds to be performed in parallel (thus improving
|
||||
performance) and allows Nix to perform multi-platform builds in a
|
||||
@@ -48,7 +50,7 @@ example configuration is shown in <xref linkend='ex-remote-systems'
|
||||
bits of information:
|
||||
|
||||
<orderedlist>
|
||||
|
||||
|
||||
<listitem><para>The name of the remote machine, with optionally the
|
||||
user under which the remote build should be performed. This is
|
||||
actually passed as an argument to <command>ssh</command>, so it can
|
||||
@@ -80,9 +82,9 @@ bits of information:
|
||||
<filename>build-remote.pl</filename> will only perform the
|
||||
derivation on a machine that has the specified features. For
|
||||
instance, the attribute
|
||||
|
||||
|
||||
<programlisting>
|
||||
requiredSystemFeatures = [ "kvm" ];
|
||||
requiredSystemFeatures = [ "kvm" ];
|
||||
</programlisting>
|
||||
|
||||
will cause the build to be performed on a machine that has the
|
||||
@@ -109,5 +111,5 @@ load on the remote machine, so if you have multiple instances of Nix
|
||||
running, they should use the same <envar>NIX_CURRENT_LOAD</envar>
|
||||
file. Maybe in the future <filename>build-remote.pl</filename> will
|
||||
look at the actual remote load.</para>
|
||||
|
||||
|
||||
</chapter>
|
||||
@@ -1,39 +0,0 @@
|
||||
<appendix xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
|
||||
<title>Bugs / To-Do</title>
|
||||
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para>The man-pages generated from the DocBook documentation
|
||||
are ugly.</para></listitem>
|
||||
|
||||
<listitem><para>Generations properly form a tree. E.g., if after
|
||||
switching to generation 39, we perform an installation action, a
|
||||
generation 43 is created which is a descendant of 39, not 42. So a
|
||||
rollback from 43 ought to go back to 39. This is not currently
|
||||
implemented; generations form a linear sequence.</para></listitem>
|
||||
|
||||
<listitem><para>For security, <command>nix-push</command> manifests
|
||||
should be digitally signed, and <command>nix-pull</command> should
|
||||
verify the signatures. The actual NAR archives in the cache do not
|
||||
need to be signed, since the manifest contains cryptographic hashes of
|
||||
these files (and <filename>fetchurl.nix</filename> checks
|
||||
them).</para></listitem>
|
||||
|
||||
<listitem><para>It would be useful to have an option in
|
||||
<command>nix-env --delete-generations</command> to remove non-current
|
||||
generations older than a certain age.</para></listitem>
|
||||
|
||||
<listitem><para>There should be a flexible way to change the user
|
||||
environment builder. Currently, you have to replace
|
||||
<filename><replaceable>prefix</replaceable>/share/nix/corepkgs/buildenv/builder.pl</filename>,
|
||||
which is hard-coded into <command>nix-env</command>. Also, the
|
||||
default builder should be more powerful. For instance, there should
|
||||
be some way to specify priorities to resolve
|
||||
collisions.</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</appendix>
|
||||
@@ -0,0 +1,20 @@
|
||||
<part xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='part-command-ref'>
|
||||
|
||||
<title>Command Reference</title>
|
||||
|
||||
<partintro>
|
||||
<para>This section lists commands and options that you can use when you
|
||||
work with Nix.</para>
|
||||
</partintro>
|
||||
|
||||
<xi:include href="opt-common.xml" />
|
||||
<xi:include href="env-common.xml" />
|
||||
<xi:include href="main-commands.xml" />
|
||||
<xi:include href="utilities.xml" />
|
||||
<xi:include href="files.xml" />
|
||||
|
||||
</part>
|
||||
@@ -7,7 +7,7 @@
|
||||
<refentrytitle>nix.conf</refentrytitle>
|
||||
<manvolnum>5</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
@@ -66,7 +66,7 @@ flag, e.g. <literal>--option gc-keep-outputs false</literal>.</para>
|
||||
<para>Keeping derivation around is useful for querying and
|
||||
traceability (e.g., it allows you to ask with what dependencies or
|
||||
options a store path was built), so by default this option is on.
|
||||
Turn it off to safe a bit of disk space (or a lot if
|
||||
Turn it off to save a bit of disk space (or a lot if
|
||||
<literal>gc-keep-outputs</literal> is also turned on).</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
@@ -101,8 +101,8 @@ flag, e.g. <literal>--option gc-keep-outputs false</literal>.</para>
|
||||
<listitem><para>This option defines the maximum number of jobs
|
||||
that Nix will try to build in parallel. The default is
|
||||
<literal>1</literal>. You should generally set it to the number
|
||||
of CPUs in your system (e.g., <literal>2</literal> on a Athlon 64
|
||||
X2). It can be overriden using the <option
|
||||
of CPUs in your system (e.g., <literal>2</literal> on an Athlon 64
|
||||
X2). It can be overridden using the <option
|
||||
linkend='opt-max-jobs'>--max-jobs</option> (<option>-j</option>)
|
||||
command line switch.</para></listitem>
|
||||
|
||||
@@ -119,7 +119,7 @@ flag, e.g. <literal>--option gc-keep-outputs false</literal>.</para>
|
||||
<varname>enableParallelBuilding</varname> is set to
|
||||
<literal>true</literal>, the builder passes the
|
||||
<option>-j<replaceable>N</replaceable></option> flag to GNU Make.
|
||||
It can be overriden using the <option
|
||||
It can be overridden using the <option
|
||||
linkend='opt-cores'>--cores</option> command line switch and
|
||||
defaults to <literal>1</literal>. The value <literal>0</literal>
|
||||
means that the builder should use all available CPU cores in the
|
||||
@@ -134,10 +134,10 @@ flag, e.g. <literal>--option gc-keep-outputs false</literal>.</para>
|
||||
|
||||
<para>This option defines the maximum number of seconds that a
|
||||
builder can go without producing any data on standard output or
|
||||
standard error. This is useful (for instance in a automated
|
||||
standard error. This is useful (for instance in an automated
|
||||
build system) to catch builds that are stuck in an infinite
|
||||
loop, or to catch remote builds that are hanging due to network
|
||||
problems. It can be overriden using the <option
|
||||
problems. It can be overridden using the <option
|
||||
linkend="opt-max-silent-time">--max-silent-time</option> command
|
||||
line switch.</para>
|
||||
|
||||
@@ -148,15 +148,16 @@ flag, e.g. <literal>--option gc-keep-outputs false</literal>.</para>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="conf-build-timeout"><term><literal>build-timeout</literal></term>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para>This option defines the maximum number of seconds that a
|
||||
builder can run. This is useful (for instance in a automated
|
||||
builder can run. This is useful (for instance in an automated
|
||||
build system) to catch builds that are stuck in an infinite loop
|
||||
but keep writing to their standard output or standard error. It
|
||||
can be overriden using the <option
|
||||
can be overridden using the <option
|
||||
linkend="opt-timeout">--timeout</option> command line
|
||||
switch.</para>
|
||||
|
||||
@@ -168,6 +169,20 @@ flag, e.g. <literal>--option gc-keep-outputs false</literal>.</para>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="conf-build-max-log-size"><term><literal>build-max-log-size</literal></term>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para>This option defines the maximum number of bytes that a
|
||||
builder can write to its stdout/stderr. If the builder exceeds
|
||||
this limit, it’s killed. A value of <literal>0</literal> (the
|
||||
default) means that there is no limit.</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="conf-build-users-group"><term><literal>build-users-group</literal></term>
|
||||
|
||||
<listitem><para>This options specifies the Unix group containing
|
||||
@@ -214,21 +229,21 @@ flag, e.g. <literal>--option gc-keep-outputs false</literal>.</para>
|
||||
<listitem><para>If set to <literal>true</literal>, builds will be
|
||||
performed in a <emphasis>chroot environment</emphasis>, i.e., the
|
||||
build will be isolated from the normal file system hierarchy and
|
||||
will only see the Nix store, the temporary build directory, and
|
||||
the directories configured with the <link
|
||||
linkend='conf-build-chroot-dirs'><literal>build-chroot-dirs</literal>
|
||||
option</link> (such as <filename>/proc</filename> and
|
||||
<filename>/dev</filename>). This is useful to prevent undeclared
|
||||
dependencies on files in directories such as
|
||||
will only see its dependencies in the Nix store, the temporary
|
||||
build directory, private versions of <filename>/proc</filename>,
|
||||
<filename>/dev</filename>, <filename>/dev/shm</filename> and
|
||||
<filename>/dev/pts</filename>, and the paths configured with the
|
||||
<link linkend='conf-build-chroot-dirs'><literal>build-chroot-dirs</literal>
|
||||
option</link>. This is useful to prevent undeclared dependencies
|
||||
on files in directories such as
|
||||
<filename>/usr/bin</filename>.</para>
|
||||
|
||||
<para>The use of a chroot requires that Nix is run as root (but
|
||||
you can still use the <link
|
||||
linkend='conf-build-users-group'>“build users” feature</link> to
|
||||
perform builds under different users than root). Currently,
|
||||
chroot builds only work on Linux because Nix uses “bind mounts” to
|
||||
make the Nix store and other directories available inside the
|
||||
chroot.</para>
|
||||
<para>The use of a chroot requires that Nix is run as root (so you
|
||||
should use the <link linkend='conf-build-users-group'>“build
|
||||
users” feature</link> to perform the actual builds under different
|
||||
users than root). Currently, chroot builds only work on Linux
|
||||
because Nix uses “bind mounts” to make the Nix store and other
|
||||
directories available inside the chroot.</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
@@ -237,20 +252,28 @@ flag, e.g. <literal>--option gc-keep-outputs false</literal>.</para>
|
||||
|
||||
<varlistentry xml:id="conf-build-chroot-dirs"><term><literal>build-chroot-dirs</literal></term>
|
||||
|
||||
<listitem><para>When builds are performed in a chroot environment,
|
||||
Nix will mount some directories from the normal file system
|
||||
hierarchy inside the chroot. These are the Nix store, the
|
||||
temporary build directory (usually
|
||||
<filename>/tmp/nix-build-<replaceable>drvname</replaceable>-<replaceable>number</replaceable></filename>),
|
||||
the <literal>/proc</literal> filesystem, and the directories
|
||||
listed here. The default is <literal>/dev /dev/pts</literal>,
|
||||
since these contain files needed by many builds (such as
|
||||
<filename>/dev/null</filename>). You can use the syntax
|
||||
<listitem><para>A list of paths bind-mounted into Nix chroot
|
||||
environments. Contrary to what the name suggests, the specified
|
||||
paths do not have to be directories; you can bind-mount other
|
||||
types of files as well. You can use the syntax
|
||||
<literal><replaceable>target</replaceable>=<replaceable>source</replaceable></literal>
|
||||
to mount a path in a different location in the chroot; for
|
||||
instance, <literal>/bin=/nix-bin</literal> will mount the
|
||||
directory <literal>/nix-bin</literal> as <literal>/bin</literal>
|
||||
inside the chroot.</para></listitem>
|
||||
instance, <literal>/bin=/nix-bin</literal> will mount the path
|
||||
<literal>/nix-bin</literal> as <literal>/bin</literal> inside the
|
||||
chroot.</para>
|
||||
|
||||
<para>Depending on how Nix was built, the default value for this option
|
||||
may be empty or provide <filename>/bin/sh</filename> as a
|
||||
bind-mount of <command>bash</command>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="conf-build-extra-chroot-dirs"><term><literal>build-extra-chroot-dirs</literal></term>
|
||||
|
||||
<listitem><para>A list of additional paths appended to
|
||||
<option>build-chroot-dirs</option>. Useful if you want to extend
|
||||
its default value.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
@@ -274,7 +297,7 @@ flag, e.g. <literal>--option gc-keep-outputs false</literal>.</para>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><literal>build-cache-failures</literal></term>
|
||||
<varlistentry><term><literal>build-cache-failure</literal></term>
|
||||
|
||||
<listitem><para>If set to <literal>true</literal>, Nix will
|
||||
“cache” build failures, meaning that it will remember (in its
|
||||
@@ -325,7 +348,7 @@ flag, e.g. <literal>--option gc-keep-outputs false</literal>.</para>
|
||||
|
||||
<listitem><para>A list of URLs of binary caches, separated by
|
||||
whitespace. The default is
|
||||
<literal>http://nixos.org/binary-cache</literal>.</para></listitem>
|
||||
<literal>https://cache.nixos.org</literal>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
@@ -350,13 +373,25 @@ flag, e.g. <literal>--option gc-keep-outputs false</literal>.</para>
|
||||
whitespace. These are not used by default, but can be enabled by
|
||||
users of the Nix daemon by specifying <literal>--option
|
||||
binary-caches <replaceable>urls</replaceable></literal> on the
|
||||
command line. Daemon users are only allowed to pass a subset of
|
||||
the URLs listed in <literal>binary-caches</literal> and
|
||||
command line. Unprivileged users are only allowed to pass a
|
||||
subset of the URLs listed in <literal>binary-caches</literal> and
|
||||
<literal>trusted-binary-caches</literal>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><literal>extra-binary-caches</literal></term>
|
||||
|
||||
<listitem><para>Additional binary caches appended to those
|
||||
specified in <option>binary-caches</option> and
|
||||
<option>binary-caches-files</option>. When used by unprivileged
|
||||
users, untrusted binary caches (i.e. those not listed in
|
||||
<option>trusted-binary-caches</option>) are silently
|
||||
ignored.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><literal>binary-caches-parallel-connections</literal></term>
|
||||
|
||||
<listitem><para>The maximum number of parallel HTTP connections
|
||||
@@ -367,6 +402,15 @@ flag, e.g. <literal>--option gc-keep-outputs false</literal>.</para>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><literal>verify-https-binary-caches</literal></term>
|
||||
|
||||
<listitem><para>Whether HTTPS binary caches are required to have a
|
||||
certificate that can be verified. Defaults to
|
||||
<literal>true</literal>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><literal>force-manifest</literal></term>
|
||||
|
||||
<listitem><para>If this option is set to <literal>false</literal>
|
||||
@@ -413,12 +457,83 @@ flag, e.g. <literal>--option gc-keep-outputs false</literal>.</para>
|
||||
|
||||
<varlistentry><term><literal>auto-optimise-store</literal></term>
|
||||
|
||||
<listitem><para>If set to <literal>true</literal> (the default),
|
||||
Nix automatically detects files in the store that have identical
|
||||
<listitem><para>If set to <literal>true</literal>, Nix
|
||||
automatically detects files in the store that have identical
|
||||
contents, and replaces them with hard links to a single copy.
|
||||
This saves disk space. If set to <literal>false</literal>, you
|
||||
can still run <command>nix-store --optimise</command> to get rid
|
||||
of duplicate files.</para></listitem>
|
||||
This saves disk space. If set to <literal>false</literal> (the
|
||||
default), you can still run <command>nix-store
|
||||
--optimise</command> to get rid of duplicate
|
||||
files.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="conf-connect-timeout"><term><literal>connect-timeout</literal></term>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para>The timeout (in seconds) for establishing connections in
|
||||
the binary cache substituter. It corresponds to
|
||||
<command>curl</command>’s <option>--connect-timeout</option>
|
||||
option.</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="conf-log-servers"><term><literal>log-servers</literal></term>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para>A list of URL prefixes (such as
|
||||
<literal>http://hydra.nixos.org/log</literal>) from which
|
||||
<command>nix-store -l</command> will try to fetch build logs if
|
||||
they’re not available locally.</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="conf-trusted-users"><term><literal>trusted-users</literal></term>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para>A list of names of users (separated by whitespace) that
|
||||
have additional rights when connecting to the Nix daemon, such
|
||||
as the ability to specify additional binary caches, or to import
|
||||
unsigned NARs. You can also specify groups by prefixing them
|
||||
with <literal>@</literal>; for instance,
|
||||
<literal>@wheel</literal> means all users in the
|
||||
<literal>wheel</literal> group. The default is
|
||||
<literal>root</literal>.</para>
|
||||
|
||||
<warning><para>The users listed here have the ability to
|
||||
compromise the security of a multi-user Nix store. For instance,
|
||||
they could install Trojan horses subsequently executed by other
|
||||
users. So you should consider carefully whether to add users to
|
||||
this list.</para></warning>
|
||||
|
||||
</listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="conf-allowed-users"><term><literal>allowed-users</literal></term>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para>A list of names of users (separated by whitespace) that
|
||||
are allowed to connect to the Nix daemon. As with the
|
||||
<option>trusted-users</option> option, you can specify groups by
|
||||
prefixing them with <literal>@</literal>. Also, you can allow
|
||||
all users by specifying <literal>*</literal>. The default is
|
||||
<literal>*</literal>.</para>
|
||||
|
||||
<para>Note that trusted users are always allowed to connect.</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
@@ -1,16 +1,18 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="sec-common-env">
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-common-env">
|
||||
|
||||
<title>Common environment variables</title>
|
||||
<title>Common Environment Variables</title>
|
||||
|
||||
|
||||
<para>Most Nix commands interpret the following environment variables:</para>
|
||||
|
||||
<variablelist xml:id="env-common">
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_PATH</envar></term>
|
||||
|
||||
<varlistentry xml:id="env-NIX_PATH"><term><envar>NIX_PATH</envar></term>
|
||||
|
||||
<listitem>
|
||||
|
||||
@@ -26,7 +28,7 @@
|
||||
<filename>/home/eelco/Dev</filename> and
|
||||
<filename>/etc/nixos</filename>, in that order. It is also
|
||||
possible to match paths against a prefix. For example, the value
|
||||
|
||||
|
||||
<screen>
|
||||
nixpkgs=/home/eelco/Dev/nixpkgs-branch:/etc/nixos</screen>
|
||||
|
||||
@@ -37,12 +39,12 @@ nixpkgs=/home/eelco/Dev/nixpkgs-branch:/etc/nixos</screen>
|
||||
<filename>/etc/nixos/nixpkgs/<replaceable>path</replaceable></filename>.
|
||||
</para>
|
||||
|
||||
<para>The search path can be extended using the
|
||||
<option>-I</option> option, which takes precedence over
|
||||
<para>The search path can be extended using the <option
|
||||
linkend="opt-I">-I</option> option, which takes precedence over
|
||||
<envar>NIX_PATH</envar>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_IGNORE_SYMLINK_STORE</envar></term>
|
||||
|
||||
@@ -65,7 +67,7 @@ nixpkgs=/home/eelco/Dev/nixpkgs-branch:/etc/nixos</screen>
|
||||
you’re better off using <literal>bind</literal> mount points, e.g.,
|
||||
|
||||
<screen>
|
||||
$ mkdir /nix
|
||||
$ mkdir /nix
|
||||
$ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
||||
|
||||
Consult the <citerefentry><refentrytitle>mount</refentrytitle>
|
||||
@@ -80,7 +82,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
||||
|
||||
<listitem><para>Overrides the location of the Nix store (default
|
||||
<filename><replaceable>prefix</replaceable>/store</filename>).</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@@ -89,7 +91,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
||||
<listitem><para>Overrides the location of the Nix static data
|
||||
directory (default
|
||||
<filename><replaceable>prefix</replaceable>/share</filename>).</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@@ -97,7 +99,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
||||
|
||||
<listitem><para>Overrides the location of the Nix log directory
|
||||
(default <filename><replaceable>prefix</replaceable>/log/nix</filename>).</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@@ -105,7 +107,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
||||
|
||||
<listitem><para>Overrides the location of the Nix state directory
|
||||
(default <filename><replaceable>prefix</replaceable>/var/nix</filename>).</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@@ -114,7 +116,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
||||
<listitem><para>Overrides the location of the Nix database (default
|
||||
<filename><replaceable>$NIX_STATE_DIR</replaceable>/db</filename>, i.e.,
|
||||
<filename><replaceable>prefix</replaceable>/var/nix/db</filename>).</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@@ -123,18 +125,9 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
||||
<listitem><para>Overrides the location of the Nix configuration
|
||||
directory (default
|
||||
<filename><replaceable>prefix</replaceable>/etc/nix</filename>).</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_LOG_TYPE</envar></term>
|
||||
|
||||
<listitem><para>Equivalent to the <link
|
||||
linkend="opt-log-type"><option>--log-type</option>
|
||||
option</link>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
|
||||
<varlistentry><term><envar>TMPDIR</envar></term>
|
||||
|
||||
@@ -142,7 +135,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
||||
files. In particular, this includes temporary build directories;
|
||||
these can take up substantial amounts of disk space. The default is
|
||||
<filename>/tmp</filename>.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@@ -240,7 +233,7 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
||||
store derivation itself).</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><filename>outputs</filename></term>
|
||||
|
||||
<listitem><para>The set of store paths that are outputs of the
|
||||
@@ -289,25 +282,21 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="envar-other-stores"><term><envar>NIX_OTHER_STORES</envar></term>
|
||||
|
||||
<listitem><para>This variable contains the paths of remote Nix
|
||||
installations from whichs paths can be copied, separated by colons.
|
||||
<phrase condition="manual">See <xref linkend="sec-sharing-packages"
|
||||
/> for details.</phrase> Each path should be the
|
||||
<filename>/nix</filename> directory of a remote Nix installation
|
||||
(i.e., not the <filename>/nix/store</filename> directory). The
|
||||
paths are subject to globbing, so you can set it so something like
|
||||
<literal>/var/run/nix/remote-stores/*/nix</literal> and mount
|
||||
multiple remote filesystems in
|
||||
<literal>/var/run/nix/remote-stores</literal>.</para>
|
||||
<varlistentry><term><envar>NIX_SHOW_STATS</envar></term>
|
||||
|
||||
<para>Note that if you’re building through the <link
|
||||
linkend="sec-nix-daemon">Nix daemon</link>, the only setting for
|
||||
this variable that matters is the one that the
|
||||
<command>nix-daemon</command> process uses. So if you want to
|
||||
change it, you have to restart the daemon.</para></listitem>
|
||||
<listitem><para>If set to <literal>1</literal>, Nix will print some
|
||||
evaluation statistics, such as the number of values
|
||||
allocated.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><envar>NIX_COUNT_CALLS</envar></term>
|
||||
|
||||
<listitem><para>If set to <literal>1</literal>, Nix will print how
|
||||
often functions were called during Nix expression evaluation. This
|
||||
is useful for profiling your Nix expressions.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
@@ -322,8 +311,8 @@ $ mount -o bind /mnt/otherdisk/nix /nix</screen>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
|
||||
</variablelist>
|
||||
|
||||
|
||||
</section>
|
||||
</chapter>
|
||||
@@ -0,0 +1,14 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='ch-files'>
|
||||
|
||||
<title>Files</title>
|
||||
|
||||
<para>This section lists configuration files that you can use when you
|
||||
work with Nix.</para>
|
||||
|
||||
<xi:include href="conf-file.xml" />
|
||||
|
||||
</chapter>
|
||||
@@ -0,0 +1,17 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='ch-main-commands'>
|
||||
|
||||
<title>Main Commands</title>
|
||||
|
||||
<para>This section lists commands and options that you can use when you
|
||||
work with Nix.</para>
|
||||
|
||||
<xi:include href="nix-env.xml" />
|
||||
<xi:include href="nix-build.xml" />
|
||||
<xi:include href="nix-shell.xml" />
|
||||
<xi:include href="nix-store.xml" />
|
||||
|
||||
</chapter>
|
||||
@@ -1,13 +1,14 @@
|
||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-nix-build">
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-build">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-build</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
@@ -38,11 +39,6 @@
|
||||
</group>
|
||||
<replaceable>outlink</replaceable>
|
||||
</arg>
|
||||
<arg>
|
||||
<option>--run-env</option>
|
||||
<arg><option>--command</option> <replaceable>cmd</replaceable></arg>
|
||||
<arg><option>--exclude</option> <replaceable>regexp</replaceable></arg>
|
||||
</arg>
|
||||
<arg choice='plain' rep='repeat'><replaceable>paths</replaceable></arg>
|
||||
</cmdsynopsis>
|
||||
</refsynopsisdiv>
|
||||
@@ -75,13 +71,6 @@ a root of the Nix garbage collector. This root disappears
|
||||
automatically when the <filename>result</filename> symlink is deleted
|
||||
or renamed. So don’t rename the symlink.</para></warning>
|
||||
|
||||
<para>The subcommand <command>nix-build --run-env</command> will build
|
||||
the dependencies of the derivation, but not the derivation itself. It
|
||||
will then start an interactive shell in which all environment
|
||||
variables defined by the derivation have been set to their
|
||||
corresponding values. This is useful for reproducing the environment
|
||||
of a derivation for development.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
@@ -134,32 +123,12 @@ also <xref linkend="sec-common-options" />.</phrase></para>
|
||||
|
||||
</variablelist>
|
||||
|
||||
<para>The following common options are supported:</para>
|
||||
|
||||
<variablelist condition="manpage">
|
||||
<xi:include href="opt-common.xml#xmlns(db=http://docbook.org/ns/docbook)xpointer(//db:variablelist[@xml:id='opt-common']/*)" />
|
||||
</variablelist>
|
||||
|
||||
<para>The following options apply to <command>nix-build --run-env</command>.</para>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><option>--command</option> <replaceable>cmd</replaceable></term>
|
||||
|
||||
<listitem><para>In the environment of the derivation, executeq the
|
||||
command <replaceable>cmd</replaceable> instead of the default
|
||||
interactive shell.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--exclude</option> <replaceable>regexp</replaceable></term>
|
||||
|
||||
<listitem><para>Do not build any dependencies whose store path
|
||||
matches the regular expression <replaceable>regexp</replaceable>.
|
||||
This option may be specified multiple times.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
@@ -176,20 +145,6 @@ lrwxrwxrwx <replaceable>...</replaceable> result -> /nix/store/d18hyl92g30l...
|
||||
$ ls ./result/bin/
|
||||
firefox firefox-config</screen>
|
||||
|
||||
<para>To build the dependencies of the package Pan, and start an
|
||||
interactive shell in which to build it:
|
||||
|
||||
<screen>
|
||||
$ nix-build '<nixpkgs>' --run-env -A pan
|
||||
$ tar xf $src
|
||||
$ cd pan-*
|
||||
$ ./configure
|
||||
$ make
|
||||
$ ./pan/gui/pan
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>If a derivation has multiple outputs,
|
||||
<command>nix-build</command> will build the default (first) output.
|
||||
You can also build all outputs:
|
||||
@@ -210,6 +165,16 @@ $ nix-build '<nixpkgs>' -A openssl.man
|
||||
</screen>
|
||||
This will create a symlink <literal>result-man</literal>.</para>
|
||||
|
||||
<para>Build a Nix expression given on the command line:
|
||||
|
||||
<screen>
|
||||
$ nix-build -E 'with import <nixpkgs> { }; runCommand "foo" { } "echo bar > $out"'
|
||||
$ cat ./result
|
||||
bar
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
@@ -0,0 +1,204 @@
|
||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-channel">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-channel</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>nix-channel</refname>
|
||||
<refpurpose>manage Nix channels</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<cmdsynopsis>
|
||||
<command>nix-channel</command>
|
||||
<group choice='req'>
|
||||
<arg choice='plain'><option>--add</option> <replaceable>url</replaceable> <arg choice='opt'><replaceable>name</replaceable></arg></arg>
|
||||
<arg choice='plain'><option>--remove</option> <replaceable>url</replaceable></arg>
|
||||
<arg choice='plain'><option>--list</option></arg>
|
||||
<arg choice='plain'><option>--update</option> <arg rep='repeat'><replaceable>names</replaceable></arg></arg>
|
||||
<arg choice='plain'><option>--rollback</option> <arg choice='opt'><replaceable>generation</replaceable></arg></arg>
|
||||
</group>
|
||||
</cmdsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
<para>A Nix channel is mechanism that allows you to automatically stay
|
||||
up-to-date with a set of pre-built Nix expressions. A Nix channel is
|
||||
just a URL that points to a place containing both a set of Nix
|
||||
expressions and a pointer to a binary cache. <phrase
|
||||
condition="manual">See also <xref linkend="sec-channels"
|
||||
/>.</phrase></para>
|
||||
|
||||
<para>This command has the following operations:
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><option>--add</option> <replaceable>url</replaceable> [<replaceable>name</replaceable>]</term>
|
||||
|
||||
<listitem><para>Adds a channel named
|
||||
<replaceable>name</replaceable> with URL
|
||||
<replaceable>url</replaceable> to the list of subscribed channels.
|
||||
If <replaceable>name</replaceable> is omitted, it defaults to the
|
||||
last component of <replaceable>url</replaceable>, with the
|
||||
suffixes <literal>-stable</literal> or
|
||||
<literal>-unstable</literal> removed.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--remove</option> <replaceable>name</replaceable></term>
|
||||
|
||||
<listitem><para>Removes the channel named
|
||||
<replaceable>name</replaceable> from the list of subscribed
|
||||
channels.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--list</option></term>
|
||||
|
||||
<listitem><para>Prints the names and URLs of all subscribed
|
||||
channels on standard output.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--update</option> [<replaceable>names</replaceable>…]</term>
|
||||
|
||||
<listitem><para>Downloads the Nix expressions of all subscribed
|
||||
channels (or only those included in
|
||||
<replaceable>names</replaceable> if specified), makes them the
|
||||
default for <command>nix-env</command> operations (by symlinking
|
||||
them from the directory <filename>~/.nix-defexpr</filename>), and
|
||||
performs a <command>nix-pull</command> on the manifests of all
|
||||
channels to make pre-built binaries available.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--rollback</option> [<replaceable>generation</replaceable>]</term>
|
||||
|
||||
<listitem><para>Reverts the previous call to <command>nix-channel
|
||||
--update</command>. Optionally, you can specify a specific channel
|
||||
generation number to restore.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Note that <option>--add</option> does not automatically perform
|
||||
an update.</para>
|
||||
|
||||
<para>The list of subscribed channels is stored in
|
||||
<filename>~/.nix-channels</filename>.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Examples</title>
|
||||
|
||||
<para>To subscribe to the Nixpkgs channel and install the GNU Hello package:</para>
|
||||
|
||||
<screen>
|
||||
$ nix-channel --add https://nixos.org/channels/nixpkgs-unstable
|
||||
$ nix-channel --update
|
||||
$ nix-env -iA nixpkgs.hello</screen>
|
||||
|
||||
<para>You can revert channel updates using <option>--rollback</option>:</para>
|
||||
|
||||
<screen>
|
||||
$ nix-instantiate --eval -E '(import <nixpkgs> {}).lib.nixpkgsVersion'
|
||||
"14.04.527.0e935f1"
|
||||
|
||||
$ nix-channel --rollback
|
||||
switching from generation 483 to 482
|
||||
|
||||
$ nix-instantiate --eval -E '(import <nixpkgs> {}).lib.nixpkgsVersion'
|
||||
"14.04.526.dbadfad"
|
||||
</screen>
|
||||
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Files</title>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><filename>/nix/var/nix/profiles/<replaceable>username</replaceable>/channels</filename></term>
|
||||
|
||||
<listitem><para><command>nix-channel</command> uses a
|
||||
<command>nix-env</command> profile to keep track of previous
|
||||
versions of the subscribed channels. Every time you run
|
||||
<command>nix-channel --update</command>, a new channel generation
|
||||
(that is, a symlink to the channel Nix expressions in the Nix store)
|
||||
is created. This enables <command>nix-channel --rollback</command>
|
||||
to revert to previous versions.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><filename>~/.nix-defexpr/channels</filename></term>
|
||||
|
||||
<listitem><para>This is a symlink to
|
||||
<filename>/nix/var/nix/profiles/<replaceable>username</replaceable>/channels</filename>. It
|
||||
ensures that <command>nix-env</command> can find your channels. In
|
||||
a multi-user installation, you may also have
|
||||
<filename>~/.nix-defexpr/channels_root</filename>, which links to
|
||||
the channels of the root user.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Channel format</title>
|
||||
|
||||
<para>A channel URL should point to a directory containing the
|
||||
following files:</para>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><filename>nixexprs.tar.xz</filename></term>
|
||||
|
||||
<listitem><para>A tarball containing Nix expressions and files
|
||||
referenced by them (such as build scripts and patches). At
|
||||
top-level, the tarball should contain a single directory. That
|
||||
directory must contain a file <filename>default.nix</filename>
|
||||
that serves as the channel’s “entry point”.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><filename>binary-cache-url</filename></term>
|
||||
|
||||
<listitem><para>A file containing the URL to a binary cache (such
|
||||
as <uri>https://cache.nixos.org</uri>. Nix will automatically
|
||||
check this cache for pre-built binaries, if the user has
|
||||
sufficient rights to add binary caches. For instance, in a
|
||||
multi-user Nix setup, the binary caches provided by the channels
|
||||
of the root user are used automatically, but caches corresponding
|
||||
to the channels of non-root users are ignored. Binary caches can
|
||||
be created and maintained using
|
||||
<command>nix-push</command>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><filename>MANIFEST.bz2</filename></term>
|
||||
|
||||
<listitem><para>(Deprecated in favour of binary caches.) A
|
||||
manifest as created by <command>nix-push</command>. Only used if
|
||||
<filename>binary-cache-url</filename> is not present or if the
|
||||
<filename>nix.conf</filename> option
|
||||
<option>force-manifest</option> is set.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
</refentry>
|
||||
@@ -1,13 +1,14 @@
|
||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-nix-collect-garbage">
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-collect-garbage">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-collect-garbage</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
@@ -20,6 +21,7 @@
|
||||
<command>nix-collect-garbage</command>
|
||||
<arg><option>--delete-old</option></arg>
|
||||
<arg><option>-d</option></arg>
|
||||
<arg><option>--delete-older-than</option> <replaceable>period</replaceable></arg>
|
||||
<group choice='opt'>
|
||||
<arg choice='plain'><option>--print-roots</option></arg>
|
||||
<arg choice='plain'><option>--print-live</option></arg>
|
||||
@@ -35,13 +37,19 @@
|
||||
<para>The command <command>nix-collect-garbage</command> is mostly an
|
||||
alias of <link linkend="rsec-nix-store-gc"><command>nix-store
|
||||
--gc</command></link>, that is, it deletes all unreachable paths in
|
||||
the Nix store to clean up your system. However, it provides an
|
||||
additional option <option>-d</option> (<option>--delete-old</option>)
|
||||
that deletes all old generations of all profiles in
|
||||
the Nix store to clean up your system. However, it provides two
|
||||
additional options: <option>-d</option> (<option>--delete-old</option>),
|
||||
which deletes all old generations of all profiles in
|
||||
<filename>/nix/var/nix/profiles</filename> by invoking
|
||||
<literal>nix-env --delete-generations old</literal> on all profiles.
|
||||
Of course, this makes rollbacks to previous configurations
|
||||
impossible.</para>
|
||||
<literal>nix-env --delete-generations old</literal> on all profiles
|
||||
(of course, this makes rollbacks to previous configurations
|
||||
impossible); and
|
||||
<option>--delete-older-than</option> <replaceable>period</replaceable>,
|
||||
where period is a value such as <literal>30d</literal>, which deletes
|
||||
all generations older than the specified number of days in all profiles
|
||||
in <filename>/nix/var/nix/profiles</filename> (except for the generations
|
||||
that were active at that point in time).
|
||||
</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
<refentrytitle>nix-copy-closure</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
@@ -24,9 +24,9 @@
|
||||
</group>
|
||||
<arg><option>--sign</option></arg>
|
||||
<arg><option>--gzip</option></arg>
|
||||
<arg><option>--bzip2</option></arg>
|
||||
<arg><option>--xz</option></arg>
|
||||
<arg><option>--show-progress</option></arg>
|
||||
<!--
|
||||
<arg><option>- -show-progress</option></arg>
|
||||
-->
|
||||
<arg><option>--include-outputs</option></arg>
|
||||
<arg><option>--use-substitutes</option></arg>
|
||||
<arg><option>-s</option></arg>
|
||||
@@ -103,22 +103,21 @@ those paths. If this bothers you, use
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--gzip</option> / <option>--bzip2</option> / <option>--xz</option></term>
|
||||
<varlistentry><term><option>--gzip</option></term>
|
||||
|
||||
<listitem><para>Compress the dump of each path with respectively
|
||||
<command>gzip</command>, <command>bzip2</command> or
|
||||
<command>xz</command> before sending it. The corresponding
|
||||
decompression program must be installed on the target
|
||||
machine.</para></listitem>
|
||||
<listitem><para>Enable compression of the SSH
|
||||
connection.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--show-progress</option></term>
|
||||
<!--
|
||||
<varlistentry><term><option>- -show-progress</option></term>
|
||||
|
||||
<listitem><para>Show the progress of each path's transfer as it's made.
|
||||
This requires the <command>pv</command> utility to be in <envar>PATH</envar>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
-->
|
||||
|
||||
<varlistentry><term><option>--include-outputs</option></term>
|
||||
|
||||
@@ -1,13 +1,14 @@
|
||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-nix-daemon">
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-daemon">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-daemon</refentrytitle>
|
||||
<manvolnum>8</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
@@ -1,13 +1,14 @@
|
||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-nix-env">
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-env">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-env</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
@@ -65,6 +66,75 @@ be performed. These are documented below.</para>
|
||||
|
||||
|
||||
|
||||
<!--######################################################################-->
|
||||
|
||||
<refsection><title>Selectors</title>
|
||||
|
||||
<para>Several commands, such as <command>nix-env -q</command> and
|
||||
<command>nix-env -i</command>, take a list of arguments that specify
|
||||
the packages on which to operate. These are extended regular
|
||||
expressions that must match the entire name of the package. (For
|
||||
details on regular expressions, see
|
||||
<citerefentry><refentrytitle>regex</refentrytitle><manvolnum>7</manvolnum></citerefentry>.)
|
||||
The match is case-sensitive. The regular expression can optionally be
|
||||
followed by a dash and a version number; if omitted, any version of
|
||||
the package will match. Here are some examples:
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>firefox</literal></term>
|
||||
<listitem><para>Matches the package name
|
||||
<literal>firefox</literal> and any version.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>firefox-32.0</literal></term>
|
||||
<listitem><para>Matches the package name
|
||||
<literal>firefox</literal> and version
|
||||
<literal>32.0</literal>.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>gtk\\+</literal></term>
|
||||
<listitem><para>Matches the package name
|
||||
<literal>gtk+</literal>. The <literal>+</literal> character must
|
||||
be escaped using a backslash to prevent it from being interpreted
|
||||
as a quantifier, and the backslash must be escaped in turn with
|
||||
another backslash to ensure that the shell passes it
|
||||
on.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>.\*</literal></term>
|
||||
<listitem><para>Matches any package name. This is the default for
|
||||
most commands.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>'.*zip.*'</literal></term>
|
||||
<listitem><para>Matches any package name containing the string
|
||||
<literal>zip</literal>. Note the dots: <literal>'*zip*'</literal>
|
||||
does not work, because in a regular expression, the character
|
||||
<literal>*</literal> is interpreted as a
|
||||
quantifier.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>'.*(firefox|chromium).*'</literal></term>
|
||||
<listitem><para>Matches any package name containing the strings
|
||||
<literal>firefox</literal> or
|
||||
<literal>chromium</literal>.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
|
||||
<!--######################################################################-->
|
||||
|
||||
<refsection><title>Common options</title>
|
||||
@@ -153,11 +223,10 @@ also <xref linkend="sec-common-options" />.</phrase></para>
|
||||
default.</para>
|
||||
|
||||
<para>The Nix expressions in this directory are combined into a
|
||||
single attribute set, with each file as an attribute that has the
|
||||
name of the file. Thus, if <filename>~/.nix-defexpr</filename>
|
||||
contains two files, <filename>foo</filename> and
|
||||
<filename>bar</filename>, then the default Nix expression will
|
||||
essentially be
|
||||
single set, with each file as an attribute that has the name of
|
||||
the file. Thus, if <filename>~/.nix-defexpr</filename> contains
|
||||
two files, <filename>foo</filename> and <filename>bar</filename>,
|
||||
then the default Nix expression will essentially be
|
||||
|
||||
<programlisting>
|
||||
{
|
||||
@@ -209,6 +278,10 @@ also <xref linkend="sec-common-options" />.</phrase></para>
|
||||
<arg choice='plain'><option>--preserve-installed</option></arg>
|
||||
<arg choice='plain'><option>-P</option></arg>
|
||||
</group>
|
||||
<group choice='opt'>
|
||||
<arg choice='plain'><option>--remove-all</option></arg>
|
||||
<arg choice='plain'><option>-r</option></arg>
|
||||
</group>
|
||||
<arg choice='plain' rep='repeat'><replaceable>args</replaceable></arg>
|
||||
</cmdsynopsis>
|
||||
|
||||
@@ -258,7 +331,7 @@ number of possible ways:
|
||||
<emphasis>attribute paths</emphasis> that select attributes from the
|
||||
top-level Nix expression. This is faster than using derivation
|
||||
names and unambiguous. To find out the attribute paths of available
|
||||
packages, use <literal>nix-env -qaP '*'</literal>.</para></listitem>
|
||||
packages, use <literal>nix-env -qaP</literal>.</para></listitem>
|
||||
|
||||
<listitem><para>If <option>--from-profile</option>
|
||||
<replaceable>path</replaceable> is given,
|
||||
@@ -272,7 +345,7 @@ number of possible ways:
|
||||
linkend="ss-functions">functions</link> that are called with the
|
||||
active Nix expression as their single argument. The derivations
|
||||
returned by those function calls are installed. This allows
|
||||
derivations to be specified in a unambiguous way, which is necessary
|
||||
derivations to be specified in an unambiguous way, which is necessary
|
||||
if there are multiple derivations with the same
|
||||
name.</para></listitem>
|
||||
|
||||
@@ -318,6 +391,16 @@ number of possible ways:
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--remove-all</option></term>
|
||||
<term><option>-r</option></term>
|
||||
|
||||
<listitem><para>Remove all previously installed packages first.
|
||||
This is equivalent to running <literal>nix-env -e '.*'</literal>
|
||||
first, except that everything happens in a single
|
||||
transaction.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
@@ -355,7 +438,7 @@ $ nix-env -i -A xorg.xorgserver</screen>
|
||||
<para>To install all derivations in the Nix expression <filename>foo.nix</filename>:
|
||||
|
||||
<screen>
|
||||
$ nix-env -f ~/foo.nix -i '*'</screen>
|
||||
$ nix-env -f ~/foo.nix -i '.*'</screen>
|
||||
|
||||
</para>
|
||||
|
||||
@@ -391,7 +474,7 @@ $ nix-env -f ./foo.nix -i -E \
|
||||
I.e., this evaluates to <literal>(f: (f {system =
|
||||
"i686-linux";}).subversionWithJava) (import ./foo.nix)</literal>, thus
|
||||
selecting the <literal>subversionWithJava</literal> attribute from the
|
||||
attribute set returned by calling the function defined in
|
||||
set returned by calling the function defined in
|
||||
<filename>./foo.nix</filename>.</para>
|
||||
|
||||
<para>A dry-run tells you which paths will be downloaded or built from
|
||||
@@ -523,7 +606,7 @@ upgrading `gcc-3.4' to `gcc-3.3.2'
|
||||
$ nix-env --upgrade pan
|
||||
<lineannotation>(no upgrades available, so nothing happens)</lineannotation>
|
||||
|
||||
$ nix-env -u '*' <lineannotation>(try to upgrade everything)</lineannotation>
|
||||
$ nix-env -u <lineannotation>(try to upgrade everything)</lineannotation>
|
||||
upgrading `hello-2.1.2' to `hello-2.1.3'
|
||||
upgrading `mozilla-1.2' to `mozilla-1.4'</screen>
|
||||
|
||||
@@ -610,7 +693,7 @@ paths designated by the symbolic names
|
||||
|
||||
<screen>
|
||||
$ nix-env --uninstall gcc
|
||||
$ nix-env -e '*' <lineannotation>(remove everything)</lineannotation></screen>
|
||||
$ nix-env -e '.*' <lineannotation>(remove everything)</lineannotation></screen>
|
||||
|
||||
</refsection>
|
||||
|
||||
@@ -686,13 +769,13 @@ After this, <command>nix-env -u</command> will ignore Firefox.</para>
|
||||
Firefox while the old remains part of the profile:
|
||||
|
||||
<screen>
|
||||
$ nix-env -q \*
|
||||
$ nix-env -q
|
||||
firefox-2.0.0.9 <lineannotation>(the current one)</lineannotation>
|
||||
|
||||
$ nix-env --preserve-installed -i firefox-2.0.0.11
|
||||
installing `firefox-2.0.0.11'
|
||||
building path(s) `/nix/store/myy0y59q3ig70dgq37jqwg1j0rsapzsl-user-environment'
|
||||
Collission between `/nix/store/<replaceable>...</replaceable>-firefox-2.0.0.11/bin/firefox'
|
||||
collision between `/nix/store/<replaceable>...</replaceable>-firefox-2.0.0.11/bin/firefox'
|
||||
and `/nix/store/<replaceable>...</replaceable>-firefox-2.0.0.9/bin/firefox'.
|
||||
<lineannotation>(i.e., can’t have two active at the same time)</lineannotation>
|
||||
|
||||
@@ -702,7 +785,7 @@ setting flag on `firefox-2.0.0.9'
|
||||
$ nix-env --preserve-installed -i firefox-2.0.0.11
|
||||
installing `firefox-2.0.0.11'
|
||||
|
||||
$ nix-env -q \*
|
||||
$ nix-env -q
|
||||
firefox-2.0.0.11 <lineannotation>(the enabled one)</lineannotation>
|
||||
firefox-2.0.0.9 <lineannotation>(the disabled one)</lineannotation></screen>
|
||||
|
||||
@@ -771,6 +854,7 @@ $ nix-env --set-flag priority 10 gcc</screen>
|
||||
<sbr />
|
||||
|
||||
<arg><option>--xml</option></arg>
|
||||
<arg><option>--json</option></arg>
|
||||
<arg>
|
||||
<group choice='req'>
|
||||
<arg choice='plain'><option>--prebuilt-only</option></arg>
|
||||
@@ -802,8 +886,7 @@ profile (<option>--installed</option>), or the derivations that are
|
||||
available for installation in the active Nix expression
|
||||
(<option>--available</option>). It only prints information about
|
||||
derivations whose symbolic name matches one of
|
||||
<replaceable>names</replaceable>. The wildcard <literal>*</literal>
|
||||
shows all derivations.</para>
|
||||
<replaceable>names</replaceable>.</para>
|
||||
|
||||
<para>The derivations are sorted by their <literal>name</literal>
|
||||
attributes.</para>
|
||||
@@ -864,6 +947,13 @@ user environment elements, etc. -->
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--json</option></term>
|
||||
|
||||
<listitem><para>Print the result in a JSON representation suitable
|
||||
for automatic processing by other tools.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--prebuild-only</option> / <option>-b</option></term>
|
||||
|
||||
<listitem><para>Show only derivations for which a substitute is
|
||||
@@ -1002,7 +1092,7 @@ user environment elements, etc. -->
|
||||
<refsection><title>Examples</title>
|
||||
|
||||
<screen>
|
||||
$ nix-env -q '*' <lineannotation>(show installed derivations)</lineannotation>
|
||||
$ nix-env -q <lineannotation>(show installed derivations)</lineannotation>
|
||||
bison-1.875c
|
||||
docbook-xml-4.2
|
||||
firefox-1.0.4
|
||||
@@ -1010,14 +1100,14 @@ MPlayer-1.0pre7
|
||||
ORBit2-2.8.3
|
||||
...
|
||||
|
||||
$ nix-env -qa '*' <lineannotation>(show available derivations)</lineannotation>
|
||||
$ nix-env -qa <lineannotation>(show available derivations)</lineannotation>
|
||||
firefox-1.0.7
|
||||
GConf-2.4.0.1
|
||||
MPlayer-1.0pre7
|
||||
ORBit2-2.8.3
|
||||
...
|
||||
|
||||
$ nix-env -qas '*' <lineannotation>(show status of available derivations)</lineannotation>
|
||||
$ nix-env -qas <lineannotation>(show status of available derivations)</lineannotation>
|
||||
-P- firefox-1.0.7 <lineannotation>(not installed but present)</lineannotation>
|
||||
--S GConf-2.4.0.1 <lineannotation>(not present, but there is a substitute for fast installation)</lineannotation>
|
||||
--S MPlayer-1.0pre3 <lineannotation>(i.e., this is not the installed MPlayer, even though the version is the same!)</lineannotation>
|
||||
@@ -1025,24 +1115,29 @@ IP- ORBit2-2.8.3 <lineannotation>(installed and by definition present)</linea
|
||||
...
|
||||
|
||||
<lineannotation>(show available derivations in the Nix expression <!-- !!! <filename>-->foo.nix<!-- </filename> -->)</lineannotation>
|
||||
$ nix-env -f ./foo.nix -qa '*'
|
||||
$ nix-env -f ./foo.nix -qa
|
||||
foo-1.2.3
|
||||
|
||||
$ nix-env -qc '*' <lineannotation>(compare installed versions to what’s available)</lineannotation>
|
||||
$ nix-env -qc <lineannotation>(compare installed versions to what’s available)</lineannotation>
|
||||
<replaceable>...</replaceable>
|
||||
acrobat-reader-7.0 - ? <lineannotation>(package is not available at all)</lineannotation>
|
||||
autoconf-2.59 = 2.59 <lineannotation>(same version)</lineannotation>
|
||||
firefox-1.0.4 < 1.0.7 <lineannotation>(a more recent version is available)</lineannotation>
|
||||
<replaceable>...</replaceable>
|
||||
|
||||
<lineannotation>(show info about a specific package, in XML)</lineannotation>
|
||||
$ nix-env -qa --xml --description firefox
|
||||
<![CDATA[<?xml version='1.0' encoding='utf-8'?>
|
||||
<items>
|
||||
<item attrPath="0.0.firefoxWrapper"
|
||||
description="Mozilla Firefox - the browser, reloaded (with various plugins)"
|
||||
name="firefox-1.5.0.7" system="i686-linux" />
|
||||
</items>]]></screen>
|
||||
$ nix-env -qa '.*zip.*' <lineannotation>(show all packages with “zip” in the name)</lineannotation>
|
||||
bzip2-1.0.6
|
||||
gzip-1.6
|
||||
zip-3.0
|
||||
<replaceable>...</replaceable>
|
||||
|
||||
$ nix-env -qa '.*(firefox|chromium).*' <lineannotation>(show all packages with “firefox” or “chromium” in the name)</lineannotation>
|
||||
chromium-37.0.2062.94
|
||||
chromium-beta-38.0.2125.24
|
||||
firefox-32.0.3
|
||||
firefox-with-plugins-13.0.1
|
||||
<replaceable>...</replaceable>
|
||||
</screen>
|
||||
|
||||
</refsection>
|
||||
|
||||
@@ -1146,10 +1241,13 @@ $ nix-env --list-generations
|
||||
<refsection><title>Description</title>
|
||||
|
||||
<para>This operation deletes the specified generations of the current
|
||||
profile. The generations can be a list of generation numbers, or the
|
||||
profile. The generations can be a list of generation numbers, the
|
||||
special value <literal>old</literal> to delete all non-current
|
||||
generations. Periodically deleting old generations is important to
|
||||
make garbage collection effective.</para>
|
||||
generations, or a value such as <literal>30d</literal> to delete all
|
||||
generations older than the specified number of days (except for the
|
||||
generation that was active at that point in time).
|
||||
Periodically deleting old generations is important to make garbage
|
||||
collection effective.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
@@ -1158,6 +1256,8 @@ make garbage collection effective.</para>
|
||||
<screen>
|
||||
$ nix-env --delete-generations 3 4 8
|
||||
|
||||
$ nix-env --delete-generations 30d
|
||||
|
||||
$ nix-env -p other_profile --delete-generations old</screen>
|
||||
|
||||
</refsection>
|
||||
@@ -1244,7 +1344,7 @@ wrapper around <option>--list-generations</option> and
|
||||
$ nix-env --rollback
|
||||
switching from generation 92 to 91
|
||||
|
||||
$ nix-env --rolback
|
||||
$ nix-env --rollback
|
||||
error: no generation older than the current (91) exists</screen>
|
||||
|
||||
</refsection>
|
||||
@@ -0,0 +1,44 @@
|
||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-generate-patches">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-generate-patches</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>nix-generate-patches</refname>
|
||||
<refpurpose>generates binary patches between NAR files</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<cmdsynopsis>
|
||||
<command>nix-generate-patches</command>
|
||||
<arg choice='plain'><replaceable>NAR-DIR</replaceable></arg>
|
||||
<arg choice='plain'><replaceable>PATCH-DIR</replaceable></arg>
|
||||
<arg choice='plain'><replaceable>PATCH-URI</replaceable></arg>
|
||||
<arg choice='plain'><replaceable>OLD-MANIFEST</replaceable></arg>
|
||||
<arg choice='plain'><replaceable>NEW-MANIFEST</replaceable></arg>
|
||||
</cmdsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
<para>The command <command>nix-generate-patches</command> generates
|
||||
binary patches between NAR files listed in OLD-MANIFEST and NEW-MANIFEST.
|
||||
The patches are written to the directory PATCH-DIR, and the prefix
|
||||
PATCH-URI is used to generate URIs for the patches. The patches are
|
||||
added to NEW-MANIFEST. All NARs are required to exist in NAR-DIR.
|
||||
Patches are generated between succeeding versions of packages with
|
||||
the same name.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
</refentry>
|
||||
@@ -1,13 +1,14 @@
|
||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-nix-hash">
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-hash">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-hash</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
@@ -1,13 +1,14 @@
|
||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-nix-install-package">
|
||||
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-install-package">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-install-package</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
@@ -26,6 +27,7 @@
|
||||
</group>
|
||||
<replaceable>path</replaceable>
|
||||
</arg>
|
||||
<arg><option>--set</option></arg>
|
||||
<sbr />
|
||||
<group choice='req'>
|
||||
<arg choice='req'>
|
||||
@@ -45,8 +47,7 @@
|
||||
<para>The command <command>nix-install-package</command> interactively
|
||||
installs a Nix Package file (<filename>*.nixpkg</filename>), which is
|
||||
a small file that contains a store path to be installed along with the
|
||||
URL of a <link linkend="sec-nix-push"><command>nix-push</command>
|
||||
manifest</link>. The Nix Package file is either
|
||||
URL of a binary cache. The Nix Package file is either
|
||||
<replaceable>file</replaceable>, or automatically downloaded from
|
||||
<replaceable>url</replaceable> if the <option>--url</option> switch is
|
||||
used.</para>
|
||||
@@ -74,7 +75,7 @@ to restart itself with <command>xterm</command>,
|
||||
<refsection><title>Options</title>
|
||||
|
||||
<variablelist>
|
||||
|
||||
|
||||
<varlistentry><term><option>--non-interactive</option></term>
|
||||
|
||||
<listitem><para>Do not open a new terminal window and do not ask
|
||||
@@ -90,6 +91,13 @@ to restart itself with <command>xterm</command>,
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--set</option></term>
|
||||
|
||||
<listitem><para>Install the package as the profile so that the
|
||||
profile contains exactly the contents of the package.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
@@ -125,19 +133,19 @@ format:
|
||||
<screen>
|
||||
NIXPKG1 <replaceable>manifestURL</replaceable> <replaceable>name</replaceable> <replaceable>system</replaceable> <replaceable>drvPath</replaceable> <replaceable>outPath</replaceable></screen>
|
||||
|
||||
The elemens are as follows:
|
||||
The elements are as follows:
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><literal>NIXPKG1</literal></term>
|
||||
|
||||
|
||||
<listitem><para>The version of the Nix Package
|
||||
file.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><replaceable>manifestURL</replaceable></term>
|
||||
|
||||
|
||||
<listitem><para>The manifest to be pulled by
|
||||
<command>nix-pull</command>. The manifest must contain
|
||||
<replaceable>outPath</replaceable>.</para></listitem>
|
||||
@@ -145,21 +153,21 @@ The elemens are as follows:
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><replaceable>name</replaceable></term>
|
||||
|
||||
|
||||
<listitem><para>The symbolic name and version of the
|
||||
package.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><replaceable>system</replaceable></term>
|
||||
|
||||
|
||||
<listitem><para>The platform identifier of the platform for which
|
||||
this binary package is intended.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><replaceable>drvPath</replaceable></term>
|
||||
|
||||
|
||||
<listitem><para>The path in the Nix store of the derivation from
|
||||
which <replaceable>outPath</replaceable> was built. Not currently
|
||||
used.</para></listitem>
|
||||
@@ -167,17 +175,21 @@ The elemens are as follows:
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><replaceable>outPath</replaceable></term>
|
||||
|
||||
<listitem><para>The path in the Nix store of the package. After
|
||||
<command>nix-install-package</command> has obtained the manifest
|
||||
from <replaceable>manifestURL</replaceable>, it performs a
|
||||
<literal>nix-env -i</literal> <replaceable>outPath</replaceable>
|
||||
to install the binary package.</para></listitem>
|
||||
|
||||
<listitem><para>The path in the Nix store of the
|
||||
package.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><replaceable>binaryCacheURL</replaceable></term>
|
||||
|
||||
<listitem><para>The URL of a binary cache containing the closure
|
||||
of <replaceable>outPath</replaceable>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
|
||||
</para>
|
||||
|
||||
<para>An example follows:
|
||||
@@ -1,13 +1,14 @@
|
||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-nix-instantiate">
|
||||
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-instantiate">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-instantiate</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
@@ -18,7 +19,15 @@
|
||||
<refsynopsisdiv>
|
||||
<cmdsynopsis>
|
||||
<command>nix-instantiate</command>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="opt-common-syn.xml#xmlns(db=http://docbook.org/ns/docbook)xpointer(/db:nop/*)" />
|
||||
<group>
|
||||
<arg choice='plain'><option>--parse</option></arg>
|
||||
<arg choice='plain'>
|
||||
<option>--eval</option>
|
||||
<arg><option>--strict</option></arg>
|
||||
<arg><option>--xml</option></arg>
|
||||
</arg>
|
||||
</group>
|
||||
<arg><option>--read-write-mode</option></arg>
|
||||
<arg><option>--arg</option> <replaceable>name</replaceable> <replaceable>value</replaceable></arg>
|
||||
<arg>
|
||||
<group choice='req'>
|
||||
@@ -29,17 +38,14 @@
|
||||
</arg>
|
||||
<arg><option>--add-root</option> <replaceable>path</replaceable></arg>
|
||||
<arg><option>--indirect</option></arg>
|
||||
<arg>
|
||||
<group choice='req'>
|
||||
<arg choice='plain'><option>--parse-only</option></arg>
|
||||
<arg choice='plain'>
|
||||
<option>--eval-only</option>
|
||||
<arg><option>--strict</option></arg>
|
||||
</arg>
|
||||
<arg choice='plain'><option>--find-file</option></arg>
|
||||
</group>
|
||||
<arg><option>--xml</option></arg>
|
||||
</arg>
|
||||
<group choice='req'>
|
||||
<arg choice='plain'><option>--expr</option></arg>
|
||||
<arg choice='plain'><option>-E</option></arg>
|
||||
</group>
|
||||
<arg choice='plain' rep='repeat'><replaceable>files</replaceable></arg>
|
||||
<sbr/>
|
||||
<command>nix-instantiate</command>
|
||||
<arg choice='plain'><option>--find-file</option></arg>
|
||||
<arg choice='plain' rep='repeat'><replaceable>files</replaceable></arg>
|
||||
</cmdsynopsis>
|
||||
</refsynopsisdiv>
|
||||
@@ -49,8 +55,8 @@
|
||||
|
||||
<para>The command <command>nix-instantiate</command> generates <link
|
||||
linkend="gloss-derivation">store derivations</link> from (high-level)
|
||||
Nix expressions. It loads and evaluates the Nix expressions in each
|
||||
of <replaceable>files</replaceable> (which defaults to
|
||||
Nix expressions. It evaluates the Nix expressions in each of
|
||||
<replaceable>files</replaceable> (which defaults to
|
||||
<replaceable>./default.nix</replaceable>). Each top-level expression
|
||||
should evaluate to a derivation, a list of derivations, or a set of
|
||||
derivations. The paths of the resulting store derivations are printed
|
||||
@@ -60,12 +66,6 @@ on standard output.</para>
|
||||
<literal>-</literal>, then a Nix expression will be read from standard
|
||||
input.</para>
|
||||
|
||||
<para>Most users and developers don’t need to use this command
|
||||
(<command>nix-env</command> and <command>nix-build</command> perform
|
||||
store derivation instantiation from Nix expressions automatically).
|
||||
It is most commonly used for implementing new deployment
|
||||
policies.</para>
|
||||
|
||||
<para condition="manual">See also <xref linkend="sec-common-options"
|
||||
/> for a list of common options.</para>
|
||||
|
||||
@@ -85,40 +85,40 @@ policies.</para>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--parse-only</option></term>
|
||||
|
||||
<varlistentry><term><option>--parse</option></term>
|
||||
|
||||
<listitem><para>Just parse the input files, and print their
|
||||
abstract syntax trees on standard output in ATerm
|
||||
format.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--eval-only</option></term>
|
||||
|
||||
|
||||
<varlistentry><term><option>--eval</option></term>
|
||||
|
||||
<listitem><para>Just parse and evaluate the input files, and print
|
||||
the resulting values on standard output. No instantiation of
|
||||
store derivations takes place.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--find-file</option></term>
|
||||
|
||||
|
||||
<listitem><para>Look up the given files in Nix’s search path (as
|
||||
specified by the <envar>NIX_PATH</envar> environment variable).
|
||||
If found, print the corresponding absolute paths on standard
|
||||
output. For instance, if <envar>NIX_PATH</envar> is
|
||||
specified by the <envar linkend="env-NIX_PATH">NIX_PATH</envar>
|
||||
environment variable). If found, print the corresponding absolute
|
||||
paths on standard output. For instance, if
|
||||
<envar>NIX_PATH</envar> is
|
||||
<literal>nixpkgs=/home/alice/nixpkgs</literal>, then
|
||||
<literal>nix-instantiate --find-file nixpkgs/default.nix</literal>
|
||||
will print
|
||||
<literal>/home/alice/nixpkgs/default.nix</literal>.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--xml</option></term>
|
||||
|
||||
<listitem><para>When used with <option>--parse-only</option> and
|
||||
<option>--eval-only</option>, print the resulting expression as an
|
||||
<listitem><para>When used with <option>--parse</option> and
|
||||
<option>--eval</option>, print the resulting expression as an
|
||||
XML representation of the abstract syntax tree rather than as an
|
||||
ATerm. The schema is the same as that used by the <link
|
||||
linkend="builtin-toXML"><function>toXML</function>
|
||||
@@ -126,9 +126,18 @@ policies.</para>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--json</option></term>
|
||||
|
||||
<listitem><para>When used with <option>--parse</option> and
|
||||
<option>--eval</option>, print the resulting expression as an
|
||||
JSON representation of the abstract syntax tree rather than as an
|
||||
ATerm.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--strict</option></term>
|
||||
|
||||
<listitem><para>When used with <option>--eval-only</option>,
|
||||
<listitem><para>When used with <option>--eval</option>,
|
||||
recursively evaluate list elements and attributes. Normally, such
|
||||
sub-expressions are left unevaluated (since the Nix expression
|
||||
language is lazy).</para>
|
||||
@@ -140,6 +149,17 @@ policies.</para>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--read-write-mode</option></term>
|
||||
|
||||
<listitem><para>When used with <option>--eval</option>, perform
|
||||
evaluation in read/write mode so nix language features that
|
||||
require it will still work (at the cost of needing to do
|
||||
instantiation of every evaluated derivation).</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
<variablelist condition="manpage">
|
||||
@@ -168,19 +188,34 @@ dr-xr-xr-x 2 eelco users 4096 1970-01-01 01:00 lib
|
||||
|
||||
</para>
|
||||
|
||||
<para>You can also give a Nix expression on the command line:
|
||||
|
||||
<screen>
|
||||
$ nix-instantiate -E 'with import <nixpkgs> { }; hello'
|
||||
/nix/store/j8s4zyv75a724q38cb0r87rlczaiag4y-hello-2.8.drv
|
||||
</screen>
|
||||
|
||||
This is equivalent to:
|
||||
|
||||
<screen>
|
||||
$ nix-instantiate '<nixpkgs>' -A hello
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Parsing and evaluating Nix expressions:
|
||||
|
||||
<screen>
|
||||
$ echo '"foo" + "bar"' | nix-instantiate --parse-only -
|
||||
OpPlus(Str("foo"),Str("bar"))
|
||||
$ nix-instantiate --parse -E '1 + 2'
|
||||
1 + 2
|
||||
|
||||
$ echo '"foo" + "bar"' | nix-instantiate --eval-only -
|
||||
Str("foobar")
|
||||
$ nix-instantiate --eval -E '1 + 2'
|
||||
3
|
||||
|
||||
$ echo '"foo" + "bar"' | nix-instantiate --eval-only --xml -
|
||||
$ nix-instantiate --eval --xml -E '1 + 2'
|
||||
<![CDATA[<?xml version='1.0' encoding='utf-8'?>
|
||||
<expr>
|
||||
<string value="foobar" />
|
||||
<int value="3" />
|
||||
</expr>]]></screen>
|
||||
|
||||
</para>
|
||||
@@ -188,28 +223,28 @@ $ echo '"foo" + "bar"' | nix-instantiate --eval-only --xml -
|
||||
<para>The difference between non-strict and strict evaluation:
|
||||
|
||||
<screen>
|
||||
$ echo 'rec { x = "foo"; y = x; }' | nix-instantiate --eval-only --xml -
|
||||
$ nix-instantiate --eval --xml -E 'rec { x = "foo"; y = x; }'
|
||||
<replaceable>...</replaceable><![CDATA[
|
||||
<attr name="x">
|
||||
<string value="foo" />
|
||||
</attr>
|
||||
<attr name="y">
|
||||
<unevaluated />
|
||||
</attr>]]>
|
||||
<attr name="x">
|
||||
<string value="foo" />
|
||||
</attr>
|
||||
<attr name="y">
|
||||
<unevaluated />
|
||||
</attr>]]>
|
||||
<replaceable>...</replaceable></screen>
|
||||
|
||||
Note that <varname>y</varname> is left unevaluated (the XML
|
||||
representation doesn’t attempt to show non-normal forms).
|
||||
|
||||
<screen>
|
||||
$ echo 'rec { x = "foo"; y = x; }' | nix-instantiate --eval-only --xml --strict -
|
||||
$ nix-instantiate --eval --xml --strict -E 'rec { x = "foo"; y = x; }'
|
||||
<replaceable>...</replaceable><![CDATA[
|
||||
<attr name="x">
|
||||
<string value="foo" />
|
||||
</attr>
|
||||
<attr name="y">
|
||||
<string value="foo" />
|
||||
</attr>]]>
|
||||
<attr name="x">
|
||||
<string value="foo" />
|
||||
</attr>
|
||||
<attr name="y">
|
||||
<string value="foo" />
|
||||
</attr>]]>
|
||||
<replaceable>...</replaceable></screen>
|
||||
|
||||
</para>
|
||||
@@ -224,6 +259,6 @@ $ echo 'rec { x = "foo"; y = x; }' | nix-instantiate --eval-only --xml --strict
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
|
||||
</refentry>
|
||||
@@ -1,13 +1,14 @@
|
||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-nix-prefetch-url">
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-prefetch-url">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-prefetch-url</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
@@ -1,18 +1,19 @@
|
||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-nix-pull">
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-pull">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-pull</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>nix-pull</refname>
|
||||
<refpurpose>pull substitutes from a network cache</refpurpose>
|
||||
<refpurpose>register availability of pre-built binaries (deprecated)</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
@@ -25,6 +26,9 @@
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
<note><para>This command and the use of manifests is deprecated. It is
|
||||
better to use binary caches.</para></note>
|
||||
|
||||
<para>The command <command>nix-pull</command> obtains a list of
|
||||
pre-built store paths from the URL <replaceable>url</replaceable>, and
|
||||
for each of these store paths, registers a substitute derivation that
|
||||
@@ -42,7 +46,7 @@ with the files created by <replaceable>nix-push</replaceable>.</para>
|
||||
<refsection><title>Examples</title>
|
||||
|
||||
<screen>
|
||||
$ nix-pull http://nix.cs.uu.nl/dist/nix/nixpkgs-0.5pre753/MANIFEST</screen>
|
||||
$ nix-pull https://nixos.org/releases/nixpkgs/nixpkgs-15.05pre54468.69858d7/MANIFEST</screen>
|
||||
|
||||
</refsection>
|
||||
|
||||
@@ -1,13 +1,14 @@
|
||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-nix-push">
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-push">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-push</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
@@ -20,6 +21,7 @@
|
||||
<command>nix-push</command>
|
||||
<arg choice='plain'><option>--dest</option> <replaceable>dest-dir</replaceable></arg>
|
||||
<arg><option>--bzip2</option></arg>
|
||||
<arg><option>--none</option></arg>
|
||||
<arg><option>--force</option></arg>
|
||||
<arg><option>--link</option></arg>
|
||||
<arg><option>--manifest</option></arg>
|
||||
@@ -106,6 +108,12 @@ automatically.</para>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--none</option></term>
|
||||
|
||||
<listitem><para>Do not compress NARs.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--force</option></term>
|
||||
|
||||
<listitem><para>Overwrite <filename>.narinfo</filename> files if
|
||||
@@ -252,7 +260,7 @@ The properties that are currently supported are:
|
||||
<listitem><para>Each binary cache has a priority (defaulting to
|
||||
50). Binary caches are checked for binaries in order of ascending
|
||||
priority; thus a higher number denotes a lower priority. The
|
||||
binary cache <uri>http://nixos.org/binary-cache</uri> has priority
|
||||
binary cache <uri>https://cache.nixos.org</uri> has priority
|
||||
40.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
@@ -270,14 +278,14 @@ URL <replaceable>url</replaceable> has a binary for
|
||||
<replaceable>p</replaceable>, Nix fetches
|
||||
<replaceable>url/h</replaceable>, where <replaceable>h</replaceable>
|
||||
is the hash part of <replaceable>p</replaceable>. Thus, if we have a
|
||||
cache <uri>http://nixos.org/binary-cache</uri> and we want to obtain
|
||||
the store path
|
||||
cache <uri>https://cache.nixos.org</uri> and we want to obtain the
|
||||
store path
|
||||
<screen>
|
||||
/nix/store/a8922c0h87iilxzzvwn2hmv8x210aqb9-glibc-2.7
|
||||
</screen>
|
||||
then Nix will attempt to fetch
|
||||
<screen>
|
||||
http://nixos.org/binary-cache/a8922c0h87iilxzzvwn2hmv8x210aqb9.narinfo
|
||||
https://cache.nixos.org/a8922c0h87iilxzzvwn2hmv8x210aqb9.narinfo
|
||||
</screen>
|
||||
(Commands such as <command>nix-env -qas</command> will issue an HTTP
|
||||
HEAD request, since it only needs to know if the
|
||||
@@ -381,7 +389,7 @@ The fields are as follows:
|
||||
references exist (e.g.,
|
||||
<filename>/nix/store/2ma2k0ys8knh4an48n28vigcmc2z8773-linux-headers-2.6.23.16</filename>),
|
||||
Nix will fetch <screen>
|
||||
http://nixos.org/binary-cache/nar/0zzjpdz46mdn74v09m053yczlz4am038g8r74iy8w43gx8801h70.nar.bz2
|
||||
https://cache.nixos.org/nar/0zzjpdz46mdn74v09m053yczlz4am038g8r74iy8w43gx8801h70.nar.bz2
|
||||
</screen> and decompress and unpack it to
|
||||
<filename>/nix/store/a8922c0h87iilxzzvwn2hmv8x210aqb9-glibc-2.7</filename>.</para>
|
||||
|
||||
@@ -0,0 +1,201 @@
|
||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-shell">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-shell</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>nix-shell</refname>
|
||||
<refpurpose>start an interactive shell based on a Nix expression</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<cmdsynopsis>
|
||||
<command>nix-shell</command>
|
||||
<arg><option>--arg</option> <replaceable>name</replaceable> <replaceable>value</replaceable></arg>
|
||||
<arg><option>--argstr</option> <replaceable>name</replaceable> <replaceable>value</replaceable></arg>
|
||||
<arg>
|
||||
<group choice='req'>
|
||||
<arg choice='plain'><option>--attr</option></arg>
|
||||
<arg choice='plain'><option>-A</option></arg>
|
||||
</group>
|
||||
<replaceable>attrPath</replaceable>
|
||||
</arg>
|
||||
<arg><option>--command</option> <replaceable>cmd</replaceable></arg>
|
||||
<arg><option>--exclude</option> <replaceable>regexp</replaceable></arg>
|
||||
<arg><option>--pure</option></arg>
|
||||
<group choice='req'>
|
||||
<group choice='plain'>
|
||||
<group>
|
||||
<arg choice='plain'><option>--packages</option></arg>
|
||||
<arg choice='plain'><option>-p</option></arg>
|
||||
</group>
|
||||
<replaceable>packages</replaceable>
|
||||
</group>
|
||||
<arg><replaceable>path</replaceable></arg>
|
||||
</group>
|
||||
</cmdsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
<para>The command <command>nix-shell</command> will build the
|
||||
dependencies of the specified derivation, but not the derivation
|
||||
itself. It will then start an interactive shell in which all
|
||||
environment variables defined by the derivation
|
||||
<replaceable>path</replaceable> have been set to their corresponding
|
||||
values, and the script <literal>$stdenv/setup</literal> has been
|
||||
sourced. This is useful for reproducing the environment of a
|
||||
derivation for development.</para>
|
||||
|
||||
<para>If <replaceable>path</replaceable> is not given,
|
||||
<command>nix-shell</command> defaults to
|
||||
<filename>shell.nix</filename> if it exists, and
|
||||
<filename>default.nix</filename> otherwise.</para>
|
||||
|
||||
<para>If the derivation defines the variable
|
||||
<varname>shellHook</varname>, it will be evaluated after
|
||||
<literal>$stdenv/setup</literal> has been sourced. Since this hook is
|
||||
not executed by regular Nix builds, it allows you to perform
|
||||
initialisation specific to <command>nix-shell</command>. For example,
|
||||
the derivation attribute
|
||||
|
||||
<programlisting>
|
||||
shellHook =
|
||||
''
|
||||
echo "Hello shell"
|
||||
'';
|
||||
</programlisting>
|
||||
|
||||
will cause <command>nix-shell</command> to print <literal>Hello shell</literal>.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Options</title>
|
||||
|
||||
<para>All options not listed here are passed to <command>nix-store
|
||||
--realise</command>, except for <option>--arg</option> and
|
||||
<option>--attr</option> / <option>-A</option> which are passed to
|
||||
<command>nix-instantiate</command>. <phrase condition="manual">See
|
||||
also <xref linkend="sec-common-options" />.</phrase></para>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><option>--command</option> <replaceable>cmd</replaceable></term>
|
||||
|
||||
<listitem><para>In the environment of the derivation, run the
|
||||
shell command <replaceable>cmd</replaceable> instead of starting
|
||||
an interactive shell. However, if you end the shell command with
|
||||
<literal>return</literal>, you still get an interactive shell.
|
||||
This can be useful for doing any additional
|
||||
initialisation.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--exclude</option> <replaceable>regexp</replaceable></term>
|
||||
|
||||
<listitem><para>Do not build any dependencies whose store path
|
||||
matches the regular expression <replaceable>regexp</replaceable>.
|
||||
This option may be specified multiple times.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--pure</option></term>
|
||||
|
||||
<listitem><para>If this flag is specified, the environment is
|
||||
almost entirely cleared before the interactive shell is started,
|
||||
so you get an environment that more closely corresponds to the
|
||||
“real” Nix build. A few variables, in particular
|
||||
<envar>HOME</envar>, <envar>USER</envar> and
|
||||
<envar>DISPLAY</envar>, are retained. Note that
|
||||
<filename>~/.bashrc</filename> and (depending on your Bash
|
||||
installation) <filename>/etc/bashrc</filename> are still sourced,
|
||||
so any variables set there will affect the interactive
|
||||
shell.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--packages</option> / <option>-p</option></term>
|
||||
|
||||
<listitem><para>Set up an environment in which the specified
|
||||
packages are present. The command line arguments are interpreted
|
||||
as attribute names inside the Nix Packages collection. Thus,
|
||||
<literal>nix-shell -p libjpeg openjdk</literal> will start a shell
|
||||
in which the packages denoted by the attribute names
|
||||
<varname>libjpeg</varname> and <varname>openjdk</varname> are
|
||||
present.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
<para>The following common options are supported:</para>
|
||||
|
||||
<variablelist condition="manpage">
|
||||
<xi:include href="opt-common.xml#xmlns(db=http://docbook.org/ns/docbook)xpointer(//db:variablelist[@xml:id='opt-common']/*)" />
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Examples</title>
|
||||
|
||||
<para>To build the dependencies of the package Pan, and start an
|
||||
interactive shell in which to build it:
|
||||
|
||||
<screen>
|
||||
$ nix-shell '<nixpkgs>' -A pan
|
||||
[nix-shell]$ unpackPhase
|
||||
[nix-shell]$ cd pan-*
|
||||
[nix-shell]$ configurePhase
|
||||
[nix-shell]$ buildPhase
|
||||
[nix-shell]$ ./pan/gui/pan
|
||||
</screen>
|
||||
|
||||
To clear the environment first, and do some additional automatic
|
||||
initialisation of the interactive shell:
|
||||
|
||||
<screen>
|
||||
$ nix-shell '<nixpkgs>' -A pan --pure \
|
||||
--command 'export NIX_DEBUG=1; export NIX_CORES=8; return'
|
||||
</screen>
|
||||
|
||||
Nix expressions can also be given on the command line. For instance,
|
||||
the following starts a shell containing the packages
|
||||
<literal>sqlite</literal> and <literal>libX11</literal>:
|
||||
|
||||
<screen>
|
||||
$ nix-shell -E 'with import <nixpkgs> { }; runCommand "dummy" { buildInputs = [ sqlite xorg.libX11 ]; } ""'
|
||||
</screen>
|
||||
|
||||
A shorter way to do the same is:
|
||||
|
||||
<screen>
|
||||
$ nix-shell -p sqlite xorg.libX11
|
||||
[nix-shell]$ echo $NIX_LDFLAGS
|
||||
… -L/nix/store/j1zg5v…-sqlite-3.8.0.2/lib -L/nix/store/0gmcz9…-libX11-1.6.1/lib …
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection condition="manpage"><title>Environment variables</title>
|
||||
|
||||
<variablelist>
|
||||
<xi:include href="env-common.xml#xmlns(db=http://docbook.org/ns/docbook)xpointer(//db:variablelist[@xml:id='env-common']/*)" />
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
</refentry>
|
||||
@@ -1,13 +1,14 @@
|
||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-nix-store">
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-nix-store">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-store</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="../version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
@@ -111,7 +112,7 @@ lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r1134
|
||||
</listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
</variablelist>
|
||||
|
||||
<variablelist condition="manpage">
|
||||
@@ -120,7 +121,7 @@ lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r1134
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
|
||||
|
||||
<!--######################################################################-->
|
||||
|
||||
@@ -141,7 +142,7 @@ lrwxrwxrwx 1 ... 2005-03-13 21:10 /home/eelco/bla/result -> /nix/store/1r1134
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
|
||||
<para>The operation <option>--realise</option> essentially “builds”
|
||||
the specified store paths. Realisation is a somewhat overloaded term:
|
||||
|
||||
@@ -164,7 +165,7 @@ the specified store paths. Realisation is a somewhat overloaded term:
|
||||
exist in the file system). If the path is already valid, we are
|
||||
done immediately. Otherwise, the path and any missing paths in its
|
||||
closure may be produced through substitutes. If there are no
|
||||
(succesful) subsitutes, realisation fails.</para></listitem>
|
||||
(successful) subsitutes, realisation fails.</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
@@ -196,14 +197,14 @@ printed.)</para>
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
|
||||
<refsection><title>Examples</title>
|
||||
|
||||
<para>This operation is typically used to build store derivations
|
||||
produced by <link
|
||||
linkend="sec-nix-instantiate"><command>nix-instantiate</command></link>:
|
||||
|
||||
|
||||
<screen>
|
||||
$ nix-store -r $(nix-instantiate ./test.nix)
|
||||
/nix/store/31axcgrlbfsxzmfff1gyj1bf62hvkby2-aterm-2.3.1</screen>
|
||||
@@ -216,7 +217,7 @@ linkend="sec-nix-build"><command>nix-build</command></link> does.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
|
||||
|
||||
<!--######################################################################-->
|
||||
|
||||
@@ -239,7 +240,7 @@ linkend="sec-nix-build"><command>nix-build</command></link> does.</para>
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
|
||||
<para>Without additional flags, the operation <option>--gc</option>
|
||||
performs a garbage collection on the Nix store. That is, all paths in
|
||||
the Nix store not reachable via file system references from a set of
|
||||
@@ -250,40 +251,40 @@ the Nix store not reachable via file system references from a set of
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><option>--print-roots</option></term>
|
||||
|
||||
|
||||
<listitem><para>This operation prints on standard output the set
|
||||
of roots used by the garbage collector. What constitutes a root
|
||||
is described in <xref linkend="ssec-gc-roots"
|
||||
/>.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--print-live</option></term>
|
||||
|
||||
|
||||
<listitem><para>This operation prints on standard output the set
|
||||
of “live” store paths, which are all the store paths reachable
|
||||
from the roots. Live paths should never be deleted, since that
|
||||
would break consistency — it would become possible that
|
||||
applications are installed that reference things that are no
|
||||
longer present in the store.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--print-dead</option></term>
|
||||
|
||||
|
||||
<listitem><para>This operation prints out on standard output the
|
||||
set of “dead” store paths, which is just the opposite of the set
|
||||
of live paths: any path in the store that is not live (with
|
||||
respect to the roots) is dead.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--delete</option></term>
|
||||
|
||||
|
||||
<listitem><para>This operation performs an actual garbage
|
||||
collection. All dead paths are removed from the
|
||||
store. This is the default.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
@@ -294,11 +295,15 @@ options control what gets deleted and in what order:
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><option>--max-freed</option> <replaceable>bytes</replaceable></term>
|
||||
|
||||
|
||||
<listitem><para>Keep deleting paths until at least
|
||||
<replaceable>bytes</replaceable> bytes have been
|
||||
deleted, then stop.</para></listitem>
|
||||
|
||||
<replaceable>bytes</replaceable> bytes have been deleted, then
|
||||
stop. The argument <replaceable>bytes</replaceable> can be
|
||||
followed by the multiplicative suffix <literal>K</literal>,
|
||||
<literal>M</literal>, <literal>G</literal> or
|
||||
<literal>T</literal>, denoting KiB, MiB, GiB or TiB
|
||||
units.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
@@ -322,7 +327,7 @@ would be freed.</para>
|
||||
<refsection><title>Examples</title>
|
||||
|
||||
<para>To delete all unreachable paths, just do:
|
||||
|
||||
|
||||
<screen>
|
||||
$ nix-store --gc
|
||||
deleting `/nix/store/kq82idx6g0nyzsp2s14gfsc38npai7lf-cairo-1.0.4.tar.gz.drv'
|
||||
@@ -344,7 +349,7 @@ $ nix-store --gc --max-freed $((100 * 1024 * 1024))</screen>
|
||||
</refsection>
|
||||
|
||||
|
||||
|
||||
|
||||
<!--######################################################################-->
|
||||
|
||||
<refsection><title>Operation <option>--delete</option></title>
|
||||
@@ -429,7 +434,7 @@ error: cannot delete path `/nix/store/zq0h41l75vlb4z45kzgjjmsjxvcv1qk7-mesa-6.4'
|
||||
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
|
||||
<para>The operation <option>--query</option> displays various bits of
|
||||
information about the store paths . The queries are described below. At
|
||||
most one query can be specified. The default query is
|
||||
@@ -449,16 +454,16 @@ query is applied to the target of the symlink.</para>
|
||||
|
||||
<varlistentry><term><option>--use-output</option></term>
|
||||
<term><option>-u</option></term>
|
||||
|
||||
|
||||
<listitem><para>For each argument to the query that is a store
|
||||
derivation, apply the query to the output path of the derivation
|
||||
instead.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--force-realise</option></term>
|
||||
<term><option>-f</option></term>
|
||||
|
||||
|
||||
<listitem><para>Realise each argument to the query first (see
|
||||
<link linkend="rsec-nix-store-realise"><command>nix-store
|
||||
--realise</command></link>).</para></listitem>
|
||||
@@ -466,12 +471,12 @@ query is applied to the target of the symlink.</para>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
|
||||
<refsection xml:id='nixref-queries'><title>Queries</title>
|
||||
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><option>--outputs</option></term>
|
||||
@@ -481,7 +486,7 @@ query is applied to the target of the symlink.</para>
|
||||
derivations <replaceable>paths</replaceable>. These are the paths
|
||||
that will be produced when the derivation is
|
||||
built.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--requisites</option></term>
|
||||
@@ -496,10 +501,10 @@ query is applied to the target of the symlink.</para>
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><option>--include-outputs</option></term>
|
||||
|
||||
|
||||
<listitem><para>Also include the output path of store
|
||||
derivations, and their closures.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
@@ -513,13 +518,13 @@ query is applied to the target of the symlink.</para>
|
||||
including binaries of build-time-only dependencies) is obtained by
|
||||
distributing the closure of a store derivation and specifying the
|
||||
option <option>--include-outputs</option>.</para>
|
||||
|
||||
|
||||
</listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--references</option></term>
|
||||
|
||||
|
||||
<listitem><para>Prints the set of <link
|
||||
linkend="gloss-reference">references</link> of the store paths
|
||||
<replaceable>paths</replaceable>, that is, their immediate
|
||||
@@ -527,9 +532,9 @@ query is applied to the target of the symlink.</para>
|
||||
<option>--requisites</option>.)</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--referrers</option></term>
|
||||
|
||||
|
||||
<listitem><para>Prints the set of <emphasis>referrers</emphasis> of
|
||||
the store paths <replaceable>paths</replaceable>, that is, the
|
||||
store paths currently existing in the Nix store that refer to one
|
||||
@@ -538,9 +543,9 @@ query is applied to the target of the symlink.</para>
|
||||
store paths are added or removed.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--referrers-closure</option></term>
|
||||
|
||||
|
||||
<listitem><para>Prints the closure of the set of store paths
|
||||
<replaceable>paths</replaceable> under the referrers relation; that
|
||||
is, all store paths that directly or indirectly refer to one of
|
||||
@@ -551,7 +556,7 @@ query is applied to the target of the symlink.</para>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--deriver</option></term>
|
||||
|
||||
|
||||
<listitem><para>Prints the <link
|
||||
linkend="gloss-deriver">deriver</link> of the store paths
|
||||
<replaceable>paths</replaceable>. If the path has no deriver
|
||||
@@ -562,7 +567,7 @@ query is applied to the target of the symlink.</para>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--graph</option></term>
|
||||
|
||||
|
||||
<listitem><para>Prints the references graph of the store paths
|
||||
<replaceable>paths</replaceable> in the format of the
|
||||
<command>dot</command> tool of AT&T's <link
|
||||
@@ -575,7 +580,7 @@ query is applied to the target of the symlink.</para>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--tree</option></term>
|
||||
|
||||
|
||||
<listitem><para>Prints the references graph of the store paths
|
||||
<replaceable>paths</replaceable> as a nested ASCII tree.
|
||||
References are ordered by descending closure size; this tends to
|
||||
@@ -587,7 +592,7 @@ query is applied to the target of the symlink.</para>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--binding</option> <replaceable>name</replaceable></term>
|
||||
|
||||
|
||||
<listitem><para>Prints the value of the attribute
|
||||
<replaceable>name</replaceable> (i.e., environment variable) of
|
||||
the store derivations <replaceable>paths</replaceable>. It is an
|
||||
@@ -597,7 +602,7 @@ query is applied to the target of the symlink.</para>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--hash</option></term>
|
||||
|
||||
|
||||
<listitem><para>Prints the SHA-256 hash of the contents of the
|
||||
store paths <replaceable>paths</replaceable> (that is, the hash of
|
||||
the output of <command>nix-store --dump</command> on the given
|
||||
@@ -607,7 +612,7 @@ query is applied to the target of the symlink.</para>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--size</option></term>
|
||||
|
||||
|
||||
<listitem><para>Prints the size in bytes of the contents of the
|
||||
store paths <replaceable>paths</replaceable> — to be precise, the
|
||||
size of the output of <command>nix-store --dump</command> on the
|
||||
@@ -618,7 +623,7 @@ query is applied to the target of the symlink.</para>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--roots</option></term>
|
||||
|
||||
|
||||
<listitem><para>Prints the garbage collector roots that point,
|
||||
directly or indirectly, at the store paths
|
||||
<replaceable>paths</replaceable>.</para></listitem>
|
||||
@@ -634,7 +639,7 @@ query is applied to the target of the symlink.</para>
|
||||
|
||||
<para>Print the closure (runtime dependencies) of the
|
||||
<command>svn</command> program in the current user environment:
|
||||
|
||||
|
||||
<screen>
|
||||
$ nix-store -qR $(which svn)
|
||||
/nix/store/5mbglq5ldqld8sj57273aljwkfvj22mc-subversion-1.1.4
|
||||
@@ -719,7 +724,7 @@ $ nix-store -q --roots $(which svn)
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
|
||||
|
||||
<!--######################################################################-->
|
||||
|
||||
@@ -735,11 +740,11 @@ $ nix-store -q --roots $(which svn)
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
|
||||
<para>TODO</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
</refsection>
|
||||
-->
|
||||
|
||||
@@ -794,7 +799,7 @@ $ nix-store --add ./foo.c
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
|
||||
<para>The operation <option>--verify</option> verifies the internal
|
||||
consistency of the Nix database, and the consistency between the Nix
|
||||
database and the Nix store. Any inconsistencies encountered are
|
||||
@@ -807,32 +812,32 @@ in Nix itself.</para>
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><option>--check-contents</option></term>
|
||||
|
||||
|
||||
<listitem><para>Checks that the contents of every valid store path
|
||||
has not been altered by computing a SHA-256 hash of the contents
|
||||
and comparing it with the hash stored in the Nix database at build
|
||||
time. Paths that have been modified are printed out. For large
|
||||
stores, <option>--check-contents</option> is obviously quite
|
||||
slow.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--repair</option></term>
|
||||
|
||||
|
||||
<listitem><para>If any valid path is missing from the store, or
|
||||
(if <option>--check-contents</option> is given) the contents of a
|
||||
valid path has been modified, then try to repair the path by
|
||||
redownloading it. See <command>nix-store --repair-path</command>
|
||||
for details.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
</variablelist>
|
||||
|
||||
</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
|
||||
</refsection>
|
||||
|
||||
@@ -851,15 +856,15 @@ in Nix itself.</para>
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
<para>The operation <option>--verify-paths</option> compares the
|
||||
|
||||
<para>The operation <option>--verify-path</option> compares the
|
||||
contents of the given store paths to their cryptographic hashes stored
|
||||
in Nix’s database. For every changed path, it prints a warning
|
||||
message. The exit status is 0 if no path has changed, and 1
|
||||
otherwise.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Example</title>
|
||||
|
||||
<para>To verify the integrity of the <command>svn</command> command and all its dependencies:
|
||||
@@ -871,7 +876,7 @@ $ nix-store --verify-path $(nix-store -qR $(which svn))
|
||||
</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
@@ -889,7 +894,7 @@ $ nix-store --verify-path $(nix-store -qR $(which svn))
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
|
||||
<para>The operation <option>--repair-path</option> attempts to
|
||||
“repair” the specified paths by redownloading them using the available
|
||||
substituters. If no substitutes are available, then repair is not
|
||||
@@ -902,7 +907,7 @@ system may be left in a broken state (e.g., if the path contains a
|
||||
critical system component like the GNU C Library).</para></warning>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Example</title>
|
||||
|
||||
<screen>
|
||||
@@ -917,7 +922,7 @@ fetching path `/nix/store/d7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13'...
|
||||
</screen>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
@@ -935,7 +940,7 @@ fetching path `/nix/store/d7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13'...
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
|
||||
<para>The operation <option>--dump</option> produces a NAR (Nix
|
||||
ARchive) file containing the contents of the file system tree rooted
|
||||
at <replaceable>path</replaceable>. The archive is written to
|
||||
@@ -966,7 +971,7 @@ links, but not other types of files (such as device nodes).</para>
|
||||
--restore</literal>.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
|
||||
</refsection>
|
||||
|
||||
@@ -985,13 +990,13 @@ links, but not other types of files (such as device nodes).</para>
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
|
||||
<para>The operation <option>--restore</option> unpacks a NAR archive
|
||||
to <replaceable>path</replaceable>, which must not already exist. The
|
||||
archive is read from standard input.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
|
||||
</refsection>
|
||||
|
||||
@@ -1010,7 +1015,7 @@ archive is read from standard input.</para>
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
|
||||
<para>The operation <option>--export</option> writes a serialisation
|
||||
of the specified store paths to standard output in a format that can
|
||||
be imported into another Nix store with <command
|
||||
@@ -1037,7 +1042,7 @@ linkend="sec-nix-copy-closure">nix-copy-closure</command>
|
||||
command.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
|
||||
</refsection>
|
||||
|
||||
@@ -1055,17 +1060,17 @@ command.</para>
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
<para>The operation <option>--export</option> reads a serialisation of
|
||||
|
||||
<para>The operation <option>--import</option> reads a serialisation of
|
||||
a set of store paths produced by <command
|
||||
linkend="refsec-nix-store-export">nix-store --import</command> from
|
||||
linkend="refsec-nix-store-export">nix-store --export</command> from
|
||||
standard input and adds those store paths to the Nix store. Paths
|
||||
that already exist in the Nix store are ignored. If a path refers to
|
||||
another path that doesn’t exist in the Nix store, the import
|
||||
fails.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
|
||||
</refsection>
|
||||
|
||||
@@ -1083,7 +1088,7 @@ fails.</para>
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
|
||||
<para>The operation <option>--optimise</option> reduces Nix store disk
|
||||
space usage by finding identical files in the store and hard-linking
|
||||
them to each other. It typically reduces the size of the store by
|
||||
@@ -1100,7 +1105,7 @@ on the achieved savings is printed on standard error.</para>
|
||||
progress indication.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Example</title>
|
||||
|
||||
<screen>
|
||||
@@ -1134,7 +1139,7 @@ there are 114486 files with equal contents out of 215894 files in total
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
|
||||
<para>The operation <option>--read-log</option> prints the build log
|
||||
of the specified store paths on standard output. The build log is
|
||||
whatever the builder of a derivation wrote to standard output and
|
||||
@@ -1143,12 +1148,17 @@ the store path is used.</para>
|
||||
|
||||
<para>Build logs are kept in
|
||||
<filename>/nix/var/log/nix/drvs</filename>. However, there is no
|
||||
guarantee that a build log is available for any particular store
|
||||
path. For instance, if the path was downloaded as a pre-built binary
|
||||
through a substitute, then the log is unavailable.</para>
|
||||
guarantee that a build log is available for any particular store path.
|
||||
For instance, if the path was downloaded as a pre-built binary through
|
||||
a substitute, then the log is unavailable. If the log is not available
|
||||
locally, then <command>nix-store</command> will try to download the
|
||||
log from the servers specified in the Nix option
|
||||
<option>log-servers</option>. For example, if it’s set to
|
||||
<literal>http://hydra.nixos.org/log</literal>, then Nix will check
|
||||
<literal>http://hydra.nixos.org/log/<replaceable>base-name</replaceable></literal>.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Example</title>
|
||||
|
||||
<screen>
|
||||
@@ -1180,14 +1190,14 @@ ktorrent-2.2.1/NEWS
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
|
||||
<para>The operation <option>--dump-db</option> writes a dump of the
|
||||
Nix database to standard output. It can be loaded into an empty Nix
|
||||
store using <option>--load-db</option>. This is useful for making
|
||||
backups and when migrating to different database schemas.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
@@ -1204,13 +1214,13 @@ backups and when migrating to different database schemas.</para>
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
|
||||
<para>The operation <option>--load-db</option> reads a dump of the Nix
|
||||
database created by <option>--dump-db</option> from standard input and
|
||||
loads it into the Nix database.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
@@ -1228,27 +1238,27 @@ loads it into the Nix database.</para>
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
|
||||
<para>The operation <option>--print-env</option> prints out the
|
||||
environment of a derivation in a format that can be evaluated by a
|
||||
shell. The command line arguments of the builder are placed in the
|
||||
variable <envar>_args</envar>.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Example</title>
|
||||
|
||||
<screen>
|
||||
$ nix-store --print-env $(nix-instantiate '<nixpkgs>' -A firefox)
|
||||
<replaceable>…</replaceable>
|
||||
export src; src='/nix/store/plpj7qrwcz94z2psh6fchsi7s8yihc7k-firefox-12.0.source.tar.bz2'
|
||||
export stdenv; stdenv='/nix/store/7c8asx3yfrg5dg1gzhzyq2236zfgibnm-stdenv'
|
||||
export stdenv; stdenv='/nix/store/7c8asx3yfrg5dg1gzhzyq2236zfgibnn-stdenv'
|
||||
export system; system='x86_64-linux'
|
||||
export _args; _args='-e /nix/store/9krlzvny65gdc8s7kpb6lkx8cd02c25b-default-builder.sh'
|
||||
export _args; _args='-e /nix/store/9krlzvny65gdc8s7kpb6lkx8cd02c25c-default-builder.sh'
|
||||
</screen>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
@@ -1265,14 +1275,14 @@ export _args; _args='-e /nix/store/9krlzvny65gdc8s7kpb6lkx8cd02c25b-default-buil
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
|
||||
<para>If build failure caching is enabled through the
|
||||
<literal>build-cache-failures</literal> configuration option, the
|
||||
<literal>build-cache-failure</literal> configuration option, the
|
||||
operation <option>--query-failed-paths</option> will print out all
|
||||
store paths that have failed to build.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Example</title>
|
||||
|
||||
<screen>
|
||||
@@ -1284,7 +1294,7 @@ $ nix-store --query-failed-paths
|
||||
</screen>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
@@ -1302,9 +1312,9 @@ $ nix-store --query-failed-paths
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
|
||||
<para>If build failure caching is enabled through the
|
||||
<literal>build-cache-failures</literal> configuration option, the
|
||||
<literal>build-cache-failure</literal> configuration option, the
|
||||
operation <option>--clear-failed-paths</option> clears the “failed”
|
||||
state of the given store paths, allowing them to be built again. This
|
||||
is useful if the failure was actually transient (e.g. because the disk
|
||||
@@ -1315,7 +1325,7 @@ You can provide the argument <literal>*</literal> to clear all store
|
||||
paths.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
<refsection><title>Example</title>
|
||||
|
||||
<screen>
|
||||
@@ -1324,7 +1334,7 @@ $ nix-store --clear-failed-paths *
|
||||
</screen>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
@@ -1337,6 +1347,6 @@ $ nix-store --clear-failed-paths *
|
||||
</variablelist>
|
||||
|
||||
</refsection>
|
||||
|
||||
|
||||
|
||||
</refentry>
|
||||
@@ -1,6 +1,6 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook" xml:id="sec-common-options">
|
||||
<chapter xmlns="http://docbook.org/ns/docbook" xml:id="sec-common-options">
|
||||
|
||||
<title>Common options</title>
|
||||
<title>Common Options</title>
|
||||
|
||||
|
||||
<para>Most Nix commands accept the following command-line options:</para>
|
||||
@@ -8,15 +8,15 @@
|
||||
<variablelist xml:id="opt-common">
|
||||
|
||||
<varlistentry><term><option>--help</option></term>
|
||||
|
||||
|
||||
<listitem><para>Prints out a summary of the command syntax and
|
||||
exits.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--version</option></term>
|
||||
|
||||
|
||||
<listitem><para>Prints out the Nix version number on standard output
|
||||
and exits.</para></listitem>
|
||||
</varlistentry>
|
||||
@@ -26,7 +26,7 @@
|
||||
<term><option>-v</option></term>
|
||||
|
||||
<listitem>
|
||||
|
||||
|
||||
<para>Increases the level of verbosity of diagnostic messages
|
||||
printed on standard error. For each Nix operation, the information
|
||||
printed on standard output is well-defined; any diagnostic
|
||||
@@ -37,18 +37,18 @@
|
||||
following verbosity levels exist:</para>
|
||||
|
||||
<variablelist>
|
||||
|
||||
|
||||
<varlistentry><term>0</term>
|
||||
<listitem><para>“Errors only”: only print messages
|
||||
explaining why the Nix invocation failed.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term>1</term>
|
||||
<listitem><para>“Informational”: print
|
||||
<emphasis>useful</emphasis> messages about what Nix is doing.
|
||||
This is the default.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term>2</term>
|
||||
<listitem><para>“Talkative”: print more informational
|
||||
messages.</para></listitem>
|
||||
@@ -68,11 +68,11 @@
|
||||
<listitem><para>“Vomit”: print vast amounts of debug
|
||||
information.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
</variablelist>
|
||||
|
||||
</listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@@ -85,7 +85,7 @@
|
||||
builder's standard output and error are always written to a log file
|
||||
in
|
||||
<filename><replaceable>prefix</replaceable>/nix/var/log/nix</filename>.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@@ -99,7 +99,7 @@
|
||||
configuration setting, which itself defaults to
|
||||
<literal>1</literal>. A higher value is useful on SMP systems or to
|
||||
exploit I/O latency.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@@ -117,7 +117,7 @@
|
||||
configuration setting, if set, or <literal>1</literal> otherwise.
|
||||
The value <literal>0</literal> means that the builder should use all
|
||||
available CPU cores in the system.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@@ -151,7 +151,7 @@
|
||||
derivation itself. Without this option, Nix stops if any build
|
||||
fails (except for builds of substitutes), possibly killing builds in
|
||||
progress (in case of parallel or distributed builds).</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@@ -181,14 +181,14 @@
|
||||
from, say, a network repository. If the repository is down, the
|
||||
realisation of the derivation will fail. When this option is
|
||||
specified, Nix will build the derivation instead. Thus,
|
||||
installation from binaries falls back on nstallation from source.
|
||||
installation from binaries falls back on installation from source.
|
||||
This option is not the default since it is generally not desirable
|
||||
for a transient failure in obtaining the substitutes to lead to a
|
||||
full build from source (with the related consumption of
|
||||
resources).</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@@ -197,7 +197,7 @@
|
||||
<listitem><para>When this option is used, no attempt is made to open
|
||||
the Nix database. Most Nix operations do need database access, so
|
||||
those operations will fail.</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@@ -236,7 +236,7 @@
|
||||
interpreted by the <command>nix-log2xml</command> tool in the
|
||||
Nix source distribution. The resulting XML file can be fed into
|
||||
the <command>log2html.xsl</command> stylesheet to create an HTML
|
||||
file that can be browsed interactively, using Javascript to
|
||||
file that can be browsed interactively, using JavaScript to
|
||||
expand and collapse parts of the output.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
@@ -247,12 +247,12 @@
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@@ -310,10 +310,10 @@
|
||||
<varlistentry xml:id="opt-attr"><term><option>--attr</option> / <option>-A</option>
|
||||
<replaceable>attrPath</replaceable></term>
|
||||
|
||||
<listitem><para>In <command>nix-env</command>,
|
||||
<command>nix-instantiate</command> and <command>nix-build</command>,
|
||||
<option>--attr</option> allows you to select an attribute from the
|
||||
top-level Nix expression being evaluated. The <emphasis>attribute
|
||||
<listitem><para>Select an attribute from the top-level Nix
|
||||
expression being evaluated. (<command>nix-env</command>,
|
||||
<command>nix-instantiate</command>, <command>nix-build</command> and
|
||||
<command>nix-shell</command> only.) The <emphasis>attribute
|
||||
path</emphasis> <replaceable>attrPath</replaceable> is a sequence of
|
||||
attribute names separated by dots. For instance, given a top-level
|
||||
Nix expression <replaceable>e</replaceable>, the attribute path
|
||||
@@ -333,32 +333,43 @@
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--expr</option> / <option>-E</option></term>
|
||||
|
||||
<listitem><para>Interpret the command line arguments as a list of
|
||||
Nix expressions to be parsed and evaluated, rather than as a list
|
||||
of file names of Nix expressions.
|
||||
(<command>nix-instantiate</command>, <command>nix-build</command>
|
||||
and <command>nix-shell</command> only.)</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--show-trace</option></term>
|
||||
|
||||
|
||||
<listitem><para>Causes Nix to print out a stack trace in case of Nix
|
||||
expression evaluation errors.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>-I</option> <replaceable>path</replaceable></term>
|
||||
|
||||
<varlistentry xml:id="opt-I"><term><option>-I</option> <replaceable>path</replaceable></term>
|
||||
|
||||
<listitem><para>Add a path to the Nix expression search path. This
|
||||
option may be given multiple times. See the <envar>NIX_PATH</envar>
|
||||
environment variable for information on the semantics of the Nix
|
||||
search path. Paths added through <option>-I</option> take
|
||||
precedence over <envar>NIX_PATH</envar>.</para></listitem>
|
||||
|
||||
option may be given multiple times. See the <envar
|
||||
linkend="env-NIX_PATH">NIX_PATH</envar> environment variable for
|
||||
information on the semantics of the Nix search path. Paths added
|
||||
through <option>-I</option> take precedence over
|
||||
<envar>NIX_PATH</envar>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><option>--option</option> <replaceable>name</replaceable> <replaceable>value</replaceable></term>
|
||||
|
||||
|
||||
<listitem><para>Set the Nix configuration option
|
||||
<replaceable>name</replaceable> to <replaceable>value</replaceable>.
|
||||
This overrides settings in the Nix configuration file (see
|
||||
<citerefentry><refentrytitle>nix.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).</para></listitem>
|
||||
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
@@ -376,4 +387,4 @@
|
||||
</variablelist>
|
||||
|
||||
|
||||
</section>
|
||||
</chapter>
|
||||
@@ -0,0 +1,26 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='ch-utilities'>
|
||||
|
||||
<title>Utilities</title>
|
||||
|
||||
<para>This section lists utilities that you can use when you
|
||||
work with Nix.</para>
|
||||
|
||||
<xi:include href="nix-channel.xml" />
|
||||
<xi:include href="nix-collect-garbage.xml" />
|
||||
<xi:include href="nix-copy-closure.xml" />
|
||||
<xi:include href="nix-daemon.xml" />
|
||||
<!--
|
||||
<xi:include href="nix-generate-patches.xml" />
|
||||
-->
|
||||
<xi:include href="nix-hash.xml" />
|
||||
<xi:include href="nix-install-package.xml" />
|
||||
<xi:include href="nix-instantiate.xml" />
|
||||
<xi:include href="nix-prefetch-url.xml" />
|
||||
<xi:include href="nix-pull.xml" />
|
||||
<xi:include href="nix-push.xml" />
|
||||
|
||||
</chapter>
|
||||
@@ -0,0 +1,262 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-advanced-attributes">
|
||||
|
||||
<title>Advanced Attributes</title>
|
||||
|
||||
<para>Derivations can declare some infrequently used optional
|
||||
attributes.</para>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><varname>allowedReferences</varname></term>
|
||||
|
||||
<listitem><para>The optional attribute
|
||||
<varname>allowedReferences</varname> specifies a list of legal
|
||||
references (dependencies) of the output of the builder. For
|
||||
example,
|
||||
|
||||
<programlisting>
|
||||
allowedReferences = [];
|
||||
</programlisting>
|
||||
|
||||
enforces that the output of a derivation cannot have any runtime
|
||||
dependencies on its inputs. To allow an output to have a runtime
|
||||
dependency on itself, use <literal>"out"</literal> as a list item.
|
||||
This is used in NixOS to check that generated files such as
|
||||
initial ramdisks for booting Linux don’t have accidental
|
||||
dependencies on other paths in the Nix store.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><varname>allowedRequisites</varname></term>
|
||||
|
||||
<listitem><para>This attribute is similar to
|
||||
<varname>allowedReferences</varname>, but it specifies the legal
|
||||
requisites of the whole closure, so all the dependencies
|
||||
recursively. For example,
|
||||
|
||||
<programlisting>
|
||||
allowedReferences = [ foobar ];
|
||||
</programlisting>
|
||||
|
||||
enforces that the output of a derivation cannot have any other
|
||||
runtime dependency than <varname>foobar</varname>, and in addition
|
||||
it enforces that <varname>foobar</varname> itself doesn't
|
||||
introduce any other dependency itself.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><varname>exportReferencesGraph</varname></term>
|
||||
|
||||
<listitem><para>This attribute allows builders access to the
|
||||
references graph of their inputs. The attribute is a list of
|
||||
inputs in the Nix store whose references graph the builder needs
|
||||
to know. The value of this attribute should be a list of pairs
|
||||
<literal>[ <replaceable>name1</replaceable>
|
||||
<replaceable>path1</replaceable> <replaceable>name2</replaceable>
|
||||
<replaceable>path2</replaceable> <replaceable>...</replaceable>
|
||||
]</literal>. The references graph of each
|
||||
<replaceable>pathN</replaceable> will be stored in a text file
|
||||
<replaceable>nameN</replaceable> in the temporary build directory.
|
||||
The text files have the format used by <command>nix-store
|
||||
--register-validity</command> (with the deriver fields left
|
||||
empty). For example, when the following derivation is built:
|
||||
|
||||
<programlisting>
|
||||
derivation {
|
||||
...
|
||||
exportReferencesGraph = [ "libfoo-graph" libfoo ];
|
||||
};
|
||||
</programlisting>
|
||||
|
||||
the references graph of <literal>libfoo</literal> is placed in the
|
||||
file <filename>libfoo-graph</filename> in the temporary build
|
||||
directory.</para>
|
||||
|
||||
<para><varname>exportReferencesGraph</varname> is useful for
|
||||
builders that want to do something with the closure of a store
|
||||
path. Examples include the builders in NixOS that generate the
|
||||
initial ramdisk for booting Linux (a <command>cpio</command>
|
||||
archive containing the closure of the boot script) and the
|
||||
ISO-9660 image for the installation CD (which is populated with a
|
||||
Nix store containing the closure of a bootable NixOS
|
||||
configuration).</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry xml:id="fixed-output-drvs">
|
||||
<term><varname>outputHash</varname></term>
|
||||
<term><varname>outputHashAlgo</varname></term>
|
||||
<term><varname>outputHashMode</varname></term>
|
||||
|
||||
<listitem><para>These attributes declare that the derivation is a
|
||||
so-called <emphasis>fixed-output derivation</emphasis>, which
|
||||
means that a cryptographic hash of the output is already known in
|
||||
advance. When the build of a fixed-output derivation finishes,
|
||||
Nix computes the cryptographic hash of the output and compares it
|
||||
to the hash declared with these attributes. If there is a
|
||||
mismatch, the build fails.</para>
|
||||
|
||||
<para>The rationale for fixed-output derivations is derivations
|
||||
such as those produced by the <function>fetchurl</function>
|
||||
function. This function downloads a file from a given URL. To
|
||||
ensure that the downloaded file has not been modified, the caller
|
||||
must also specify a cryptographic hash of the file. For example,
|
||||
|
||||
<programlisting>
|
||||
fetchurl {
|
||||
url = http://ftp.gnu.org/pub/gnu/hello/hello-2.1.1.tar.gz;
|
||||
md5 = "70c9ccf9fac07f762c24f2df2290784d";
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
It sometimes happens that the URL of the file changes, e.g.,
|
||||
because servers are reorganised or no longer available. We then
|
||||
must update the call to <function>fetchurl</function>, e.g.,
|
||||
|
||||
<programlisting>
|
||||
fetchurl {
|
||||
url = ftp://ftp.nluug.nl/pub/gnu/hello/hello-2.1.1.tar.gz;
|
||||
md5 = "70c9ccf9fac07f762c24f2df2290784d";
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
If a <function>fetchurl</function> derivation was treated like a
|
||||
normal derivation, the output paths of the derivation and
|
||||
<emphasis>all derivations depending on it</emphasis> would change.
|
||||
For instance, if we were to change the URL of the Glibc source
|
||||
distribution in Nixpkgs (a package on which almost all other
|
||||
packages depend) massive rebuilds would be needed. This is
|
||||
unfortunate for a change which we know cannot have a real effect
|
||||
as it propagates upwards through the dependency graph.</para>
|
||||
|
||||
<para>For fixed-output derivations, on the other hand, the name of
|
||||
the output path only depends on the <varname>outputHash*</varname>
|
||||
and <varname>name</varname> attributes, while all other attributes
|
||||
are ignored for the purpose of computing the output path. (The
|
||||
<varname>name</varname> attribute is included because it is part
|
||||
of the path.)</para>
|
||||
|
||||
<para>As an example, here is the (simplified) Nix expression for
|
||||
<varname>fetchurl</varname>:
|
||||
|
||||
<programlisting>
|
||||
{ stdenv, curl }: # The <command>curl</command> program is used for downloading.
|
||||
|
||||
{ url, md5 }:
|
||||
|
||||
stdenv.mkDerivation {
|
||||
name = baseNameOf (toString url);
|
||||
builder = ./builder.sh;
|
||||
buildInputs = [ curl ];
|
||||
|
||||
# This is a fixed-output derivation; the output must be a regular
|
||||
# file with MD5 hash <varname>md5</varname>.
|
||||
outputHashMode = "flat";
|
||||
outputHashAlgo = "md5";
|
||||
outputHash = md5;
|
||||
|
||||
inherit url;
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
</para>
|
||||
|
||||
<para>The <varname>outputHashAlgo</varname> attribute specifies
|
||||
the hash algorithm used to compute the hash. It can currently be
|
||||
<literal>"md5"</literal>, <literal>"sha1"</literal> or
|
||||
<literal>"sha256"</literal>.</para>
|
||||
|
||||
<para>The <varname>outputHashMode</varname> attribute determines
|
||||
how the hash is computed. It must be one of the following two
|
||||
values:
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><literal>"flat"</literal></term>
|
||||
|
||||
<listitem><para>The output must be a non-executable regular
|
||||
file. If it isn’t, the build fails. The hash is simply
|
||||
computed over the contents of that file (so it’s equal to what
|
||||
Unix commands like <command>md5sum</command> or
|
||||
<command>sha1sum</command> produce).</para>
|
||||
|
||||
<para>This is the default.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><literal>"recursive"</literal></term>
|
||||
|
||||
<listitem><para>The hash is computed over the NAR archive dump
|
||||
of the output (i.e., the result of <link
|
||||
linkend="refsec-nix-store-dump"><command>nix-store
|
||||
--dump</command></link>). In this case, the output can be
|
||||
anything, including a directory tree.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</para>
|
||||
|
||||
<para>The <varname>outputHash</varname> attribute, finally, must
|
||||
be a string containing the hash in either hexadecimal or base-32
|
||||
notation. (See the <link
|
||||
linkend="sec-nix-hash"><command>nix-hash</command> command</link>
|
||||
for information about converting to and from base-32
|
||||
notation.)</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><varname>impureEnvVars</varname></term>
|
||||
|
||||
<listitem><para>This attribute allows you to specify a list of
|
||||
environment variables that should be passed from the environment
|
||||
of the calling user to the builder. Usually, the environment is
|
||||
cleared completely when the builder is executed, but with this
|
||||
attribute you can allow specific environment variables to be
|
||||
passed unmodified. For example, <function>fetchurl</function> in
|
||||
Nixpkgs has the line
|
||||
|
||||
<programlisting>
|
||||
impureEnvVars = [ "http_proxy" "https_proxy" <replaceable>...</replaceable> ];
|
||||
</programlisting>
|
||||
|
||||
to make it use the proxy server configuration specified by the
|
||||
user in the environment variables <envar>http_proxy</envar> and
|
||||
friends.</para>
|
||||
|
||||
<para>This attribute is only allowed in <link
|
||||
linkend="fixed-output-drvs">fixed-output derivations</link>, where
|
||||
impurities such as these are okay since (the hash of) the output
|
||||
is known in advance. It is ignored for all other
|
||||
derivations.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><varname>preferLocalBuild</varname></term>
|
||||
|
||||
<listitem><para>If this attribute is set to
|
||||
<literal>true</literal>, it has two effects. First, the
|
||||
derivation will always be built, not substituted, even if a
|
||||
substitute is available. Second, if <link
|
||||
linkend="chap-distributed-builds">distributed building is
|
||||
enabled</link>, then, if possible, the derivaton will be built
|
||||
locally instead of forwarded to a remote machine. This is
|
||||
appropriate for trivial builders where the cost of doing a
|
||||
download or remote build would exceed the cost of building
|
||||
locally.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</section>
|
||||
@@ -0,0 +1,121 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='sec-arguments'>
|
||||
|
||||
<title>Arguments and Variables</title>
|
||||
|
||||
<example xml:id='ex-hello-composition'>
|
||||
|
||||
<title>Composing GNU Hello
|
||||
(<filename>all-packages.nix</filename>)</title>
|
||||
<programlisting>
|
||||
...
|
||||
|
||||
rec { <co xml:id='ex-hello-composition-co-1' />
|
||||
|
||||
hello = import ../applications/misc/hello/ex-1 <co xml:id='ex-hello-composition-co-2' /> { <co xml:id='ex-hello-composition-co-3' />
|
||||
inherit fetchurl stdenv perl;
|
||||
};
|
||||
|
||||
perl = import ../development/interpreters/perl { <co xml:id='ex-hello-composition-co-4' />
|
||||
inherit fetchurl stdenv;
|
||||
};
|
||||
|
||||
fetchurl = import ../build-support/fetchurl {
|
||||
inherit stdenv; ...
|
||||
};
|
||||
|
||||
stdenv = ...;
|
||||
|
||||
}
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<para>The Nix expression in <xref linkend='ex-hello-nix' /> is a
|
||||
function; it is missing some arguments that have to be filled in
|
||||
somewhere. In the Nix Packages collection this is done in the file
|
||||
<filename>pkgs/top-level/all-packages.nix</filename>, where all
|
||||
Nix expressions for packages are imported and called with the
|
||||
appropriate arguments. <xref linkend='ex-hello-composition' /> shows
|
||||
some fragments of
|
||||
<filename>all-packages.nix</filename>.</para>
|
||||
|
||||
<calloutlist>
|
||||
|
||||
<callout arearefs='ex-hello-composition-co-1'>
|
||||
|
||||
<para>This file defines a set of attributes, all of which are
|
||||
concrete derivations (i.e., not functions). In fact, we define a
|
||||
<emphasis>mutually recursive</emphasis> set of attributes. That
|
||||
is, the attributes can refer to each other. This is precisely
|
||||
what we want since we want to <quote>plug</quote> the
|
||||
various packages into each other.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-composition-co-2'>
|
||||
|
||||
<para>Here we <emphasis>import</emphasis> the Nix expression for
|
||||
GNU Hello. The import operation just loads and returns the
|
||||
specified Nix expression. In fact, we could just have put the
|
||||
contents of <xref linkend='ex-hello-nix' /> in
|
||||
<filename>all-packages.nix</filename> at this point. That
|
||||
would be completely equivalent, but it would make the file rather
|
||||
bulky.</para>
|
||||
|
||||
<para>Note that we refer to
|
||||
<filename>../applications/misc/hello/ex-1</filename>, not
|
||||
<filename>../applications/misc/hello/ex-1/default.nix</filename>.
|
||||
When you try to import a directory, Nix automatically appends
|
||||
<filename>/default.nix</filename> to the file name.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-composition-co-3'>
|
||||
|
||||
<para>This is where the actual composition takes place. Here we
|
||||
<emphasis>call</emphasis> the function imported from
|
||||
<filename>../applications/misc/hello/ex-1</filename> with a set
|
||||
containing the things that the function expects, namely
|
||||
<varname>fetchurl</varname>, <varname>stdenv</varname>, and
|
||||
<varname>perl</varname>. We use inherit again to use the
|
||||
attributes defined in the surrounding scope (we could also have
|
||||
written <literal>fetchurl = fetchurl;</literal>, etc.).</para>
|
||||
|
||||
<para>The result of this function call is an actual derivation
|
||||
that can be built by Nix (since when we fill in the arguments of
|
||||
the function, what we get is its body, which is the call to
|
||||
<varname>stdenv.mkDerivation</varname> in <xref
|
||||
linkend='ex-hello-nix' />).</para>
|
||||
|
||||
<note><para>Nixpkgs has a convenience function
|
||||
<function>callPackage</function> that imports and calls a
|
||||
function, filling in any missing arguments by passing the
|
||||
corresponding attribute from the Nixpkgs set, like this:
|
||||
|
||||
<programlisting>
|
||||
hello = callPackage ../applications/misc/hello/ex-1 { };
|
||||
</programlisting>
|
||||
|
||||
If necessary, you can set or override arguments:
|
||||
|
||||
<programlisting>
|
||||
hello = callPackage ../applications/misc/hello/ex-1 { stdenv = myStdenv; };
|
||||
</programlisting>
|
||||
|
||||
</para></note>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-composition-co-4'>
|
||||
|
||||
<para>Likewise, we have to instantiate Perl,
|
||||
<varname>fetchurl</varname>, and the standard environment.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
</calloutlist>
|
||||
|
||||
</section>
|
||||
@@ -0,0 +1,119 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='sec-build-script'>
|
||||
|
||||
<title>Build Script</title>
|
||||
|
||||
<example xml:id='ex-hello-builder'><title>Build script for GNU Hello
|
||||
(<filename>builder.sh</filename>)</title>
|
||||
<programlisting>
|
||||
source $stdenv/setup <co xml:id='ex-hello-builder-co-1' />
|
||||
|
||||
PATH=$perl/bin:$PATH <co xml:id='ex-hello-builder-co-2' />
|
||||
|
||||
tar xvfz $src <co xml:id='ex-hello-builder-co-3' />
|
||||
cd hello-*
|
||||
./configure --prefix=$out <co xml:id='ex-hello-builder-co-4' />
|
||||
make <co xml:id='ex-hello-builder-co-5' />
|
||||
make install</programlisting>
|
||||
</example>
|
||||
|
||||
<para><xref linkend='ex-hello-builder' /> shows the builder referenced
|
||||
from Hello's Nix expression (stored in
|
||||
<filename>pkgs/applications/misc/hello/ex-1/builder.sh</filename>).
|
||||
The builder can actually be made a lot shorter by using the
|
||||
<emphasis>generic builder</emphasis> functions provided by
|
||||
<varname>stdenv</varname>, but here we write out the build steps to
|
||||
elucidate what a builder does. It performs the following
|
||||
steps:</para>
|
||||
|
||||
<calloutlist>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-1'>
|
||||
|
||||
<para>When Nix runs a builder, it initially completely clears the
|
||||
environment (except for the attributes declared in the
|
||||
derivation). For instance, the <envar>PATH</envar> variable is
|
||||
empty<footnote><para>Actually, it's initialised to
|
||||
<filename>/path-not-set</filename> to prevent Bash from setting it
|
||||
to a default value.</para></footnote>. This is done to prevent
|
||||
undeclared inputs from being used in the build process. If for
|
||||
example the <envar>PATH</envar> contained
|
||||
<filename>/usr/bin</filename>, then you might accidentally use
|
||||
<filename>/usr/bin/gcc</filename>.</para>
|
||||
|
||||
<para>So the first step is to set up the environment. This is
|
||||
done by calling the <filename>setup</filename> script of the
|
||||
standard environment. The environment variable
|
||||
<envar>stdenv</envar> points to the location of the standard
|
||||
environment being used. (It wasn't specified explicitly as an
|
||||
attribute in <xref linkend='ex-hello-nix' />, but
|
||||
<varname>mkDerivation</varname> adds it automatically.)</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-2'>
|
||||
|
||||
<para>Since Hello needs Perl, we have to make sure that Perl is in
|
||||
the <envar>PATH</envar>. The <envar>perl</envar> environment
|
||||
variable points to the location of the Perl package (since it
|
||||
was passed in as an attribute to the derivation), so
|
||||
<filename><replaceable>$perl</replaceable>/bin</filename> is the
|
||||
directory containing the Perl interpreter.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-3'>
|
||||
|
||||
<para>Now we have to unpack the sources. The
|
||||
<varname>src</varname> attribute was bound to the result of
|
||||
fetching the Hello source tarball from the network, so the
|
||||
<envar>src</envar> environment variable points to the location in
|
||||
the Nix store to which the tarball was downloaded. After
|
||||
unpacking, we <command>cd</command> to the resulting source
|
||||
directory.</para>
|
||||
|
||||
<para>The whole build is performed in a temporary directory
|
||||
created in <varname>/tmp</varname>, by the way. This directory is
|
||||
removed after the builder finishes, so there is no need to clean
|
||||
up the sources afterwards. Also, the temporary directory is
|
||||
always newly created, so you don't have to worry about files from
|
||||
previous builds interfering with the current build.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-4'>
|
||||
|
||||
<para>GNU Hello is a typical Autoconf-based package, so we first
|
||||
have to run its <filename>configure</filename> script. In Nix
|
||||
every package is stored in a separate location in the Nix store,
|
||||
for instance
|
||||
<filename>/nix/store/9a54ba97fb71b65fda531012d0443ce2-hello-2.1.1</filename>.
|
||||
Nix computes this path by cryptographically hashing all attributes
|
||||
of the derivation. The path is passed to the builder through the
|
||||
<envar>out</envar> environment variable. So here we give
|
||||
<filename>configure</filename> the parameter
|
||||
<literal>--prefix=$out</literal> to cause Hello to be installed in
|
||||
the expected location.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-5'>
|
||||
|
||||
<para>Finally we build Hello (<literal>make</literal>) and install
|
||||
it into the location specified by <envar>out</envar>
|
||||
(<literal>make install</literal>).</para>
|
||||
|
||||
</callout>
|
||||
|
||||
</calloutlist>
|
||||
|
||||
<para>If you are wondering about the absence of error checking on the
|
||||
result of various commands called in the builder: this is because the
|
||||
shell script is evaluated with Bash's <option>-e</option> option,
|
||||
which causes the script to be aborted if any command fails without an
|
||||
error check.</para>
|
||||
|
||||
</section>
|
||||
@@ -0,0 +1,119 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='sec-builder-syntax'>
|
||||
|
||||
<title>Builder Syntax</title>
|
||||
|
||||
<example xml:id='ex-hello-builder'><title>Build script for GNU Hello
|
||||
(<filename>builder.sh</filename>)</title>
|
||||
<programlisting>
|
||||
source $stdenv/setup <co xml:id='ex-hello-builder-co-1' />
|
||||
|
||||
PATH=$perl/bin:$PATH <co xml:id='ex-hello-builder-co-2' />
|
||||
|
||||
tar xvfz $src <co xml:id='ex-hello-builder-co-3' />
|
||||
cd hello-*
|
||||
./configure --prefix=$out <co xml:id='ex-hello-builder-co-4' />
|
||||
make <co xml:id='ex-hello-builder-co-5' />
|
||||
make install</programlisting>
|
||||
</example>
|
||||
|
||||
<para><xref linkend='ex-hello-builder' /> shows the builder referenced
|
||||
from Hello's Nix expression (stored in
|
||||
<filename>pkgs/applications/misc/hello/ex-1/builder.sh</filename>).
|
||||
The builder can actually be made a lot shorter by using the
|
||||
<emphasis>generic builder</emphasis> functions provided by
|
||||
<varname>stdenv</varname>, but here we write out the build steps to
|
||||
elucidate what a builder does. It performs the following
|
||||
steps:</para>
|
||||
|
||||
<calloutlist>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-1'>
|
||||
|
||||
<para>When Nix runs a builder, it initially completely clears the
|
||||
environment (except for the attributes declared in the
|
||||
derivation). For instance, the <envar>PATH</envar> variable is
|
||||
empty<footnote><para>Actually, it's initialised to
|
||||
<filename>/path-not-set</filename> to prevent Bash from setting it
|
||||
to a default value.</para></footnote>. This is done to prevent
|
||||
undeclared inputs from being used in the build process. If for
|
||||
example the <envar>PATH</envar> contained
|
||||
<filename>/usr/bin</filename>, then you might accidentally use
|
||||
<filename>/usr/bin/gcc</filename>.</para>
|
||||
|
||||
<para>So the first step is to set up the environment. This is
|
||||
done by calling the <filename>setup</filename> script of the
|
||||
standard environment. The environment variable
|
||||
<envar>stdenv</envar> points to the location of the standard
|
||||
environment being used. (It wasn't specified explicitly as an
|
||||
attribute in <xref linkend='ex-hello-nix' />, but
|
||||
<varname>mkDerivation</varname> adds it automatically.)</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-2'>
|
||||
|
||||
<para>Since Hello needs Perl, we have to make sure that Perl is in
|
||||
the <envar>PATH</envar>. The <envar>perl</envar> environment
|
||||
variable points to the location of the Perl package (since it
|
||||
was passed in as an attribute to the derivation), so
|
||||
<filename><replaceable>$perl</replaceable>/bin</filename> is the
|
||||
directory containing the Perl interpreter.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-3'>
|
||||
|
||||
<para>Now we have to unpack the sources. The
|
||||
<varname>src</varname> attribute was bound to the result of
|
||||
fetching the Hello source tarball from the network, so the
|
||||
<envar>src</envar> environment variable points to the location in
|
||||
the Nix store to which the tarball was downloaded. After
|
||||
unpacking, we <command>cd</command> to the resulting source
|
||||
directory.</para>
|
||||
|
||||
<para>The whole build is performed in a temporary directory
|
||||
created in <varname>/tmp</varname>, by the way. This directory is
|
||||
removed after the builder finishes, so there is no need to clean
|
||||
up the sources afterwards. Also, the temporary directory is
|
||||
always newly created, so you don't have to worry about files from
|
||||
previous builds interfering with the current build.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-4'>
|
||||
|
||||
<para>GNU Hello is a typical Autoconf-based package, so we first
|
||||
have to run its <filename>configure</filename> script. In Nix
|
||||
every package is stored in a separate location in the Nix store,
|
||||
for instance
|
||||
<filename>/nix/store/9a54ba97fb71b65fda531012d0443ce2-hello-2.1.1</filename>.
|
||||
Nix computes this path by cryptographically hashing all attributes
|
||||
of the derivation. The path is passed to the builder through the
|
||||
<envar>out</envar> environment variable. So here we give
|
||||
<filename>configure</filename> the parameter
|
||||
<literal>--prefix=$out</literal> to cause Hello to be installed in
|
||||
the expected location.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder-co-5'>
|
||||
|
||||
<para>Finally we build Hello (<literal>make</literal>) and install
|
||||
it into the location specified by <envar>out</envar>
|
||||
(<literal>make install</literal>).</para>
|
||||
|
||||
</callout>
|
||||
|
||||
</calloutlist>
|
||||
|
||||
<para>If you are wondering about the absence of error checking on the
|
||||
result of various commands called in the builder: this is because the
|
||||
shell script is evaluated with Bash's <option>-e</option> option,
|
||||
which causes the script to be aborted if any command fails without an
|
||||
error check.</para>
|
||||
|
||||
</section>
|
||||
@@ -1,9 +1,10 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id='ssec-builtins'>
|
||||
|
||||
<title>Built-in functions</title>
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='ssec-builtins'>
|
||||
|
||||
<title>Built-in Functions</title>
|
||||
|
||||
<para>This section lists the functions and constants built into the
|
||||
Nix expression evaluator. (The built-in function
|
||||
@@ -12,9 +13,9 @@ such as <function>derivation</function>, are always in scope of every
|
||||
Nix expression; you can just access them right away. But to prevent
|
||||
polluting the namespace too much, most built-ins are not in scope.
|
||||
Instead, you can access them through the <varname>builtins</varname>
|
||||
built-in value, which is an attribute set that contains all built-in
|
||||
functions and values. For instance, <function>derivation</function>
|
||||
is also available as <function>builtins.derivation</function>.</para>
|
||||
built-in value, which is a set that contains all built-in functions
|
||||
and values. For instance, <function>derivation</function> is also
|
||||
available as <function>builtins.derivation</function>.</para>
|
||||
|
||||
|
||||
<variablelist>
|
||||
@@ -39,19 +40,22 @@ is also available as <function>builtins.derivation</function>.</para>
|
||||
|
||||
|
||||
<varlistentry><term><function>builtins.attrNames</function>
|
||||
<replaceable>attrs</replaceable></term>
|
||||
<replaceable>set</replaceable></term>
|
||||
|
||||
<listitem><para>Return the names of the attributes in the
|
||||
attribute set <replaceable>attrs</replaceable> in a sorted list.
|
||||
For instance, <literal>builtins.attrNames { y = 1; x = "foo";
|
||||
}</literal> evaluates to <literal>[ "x" "y" ]</literal>. There is
|
||||
no built-in function <function>attrValues</function>, but you can
|
||||
easily define it yourself:
|
||||
<listitem><para>Return the names of the attributes in the set
|
||||
<replaceable>set</replaceable> in a sorted list. For instance,
|
||||
<literal>builtins.attrNames { y = 1; x = "foo"; }</literal>
|
||||
evaluates to <literal>[ "x" "y" ]</literal>.</para></listitem>
|
||||
|
||||
<programlisting>
|
||||
attrValues = attrs: map (name: builtins.getAttr name attrs) (builtins.attrNames attrs);</programlisting>
|
||||
</varlistentry>
|
||||
|
||||
</para></listitem>
|
||||
|
||||
<varlistentry><term><function>builtins.attrValues</function>
|
||||
<replaceable>set</replaceable></term>
|
||||
|
||||
<listitem><para>Return the values of the attributes in the set
|
||||
<replaceable>set</replaceable> in the order corresponding to the
|
||||
sorted attribute names.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
@@ -68,8 +72,8 @@ attrValues = attrs: map (name: builtins.getAttr name attrs) (builtins.attrNames
|
||||
|
||||
<varlistentry><term><varname>builtins</varname></term>
|
||||
|
||||
<listitem><para>The attribute set <varname>builtins</varname>
|
||||
contains all the built-in functions and values. You can use
|
||||
<listitem><para>The set <varname>builtins</varname> contains all
|
||||
the built-in functions and values. You can use
|
||||
<varname>builtins</varname> to test for the availability of
|
||||
features in the Nix installation, e.g.,
|
||||
|
||||
@@ -143,6 +147,19 @@ if builtins ? getEnv then builtins.getEnv "PATH" else ""</programlisting>
|
||||
-->
|
||||
|
||||
|
||||
<varlistentry><term><function>builtins.deepSeq</function>
|
||||
<replaceable>e1</replaceable> <replaceable>e2</replaceable></term>
|
||||
|
||||
<listitem><para>This is like <literal>seq
|
||||
<replaceable>e1</replaceable>
|
||||
<replaceable>e2</replaceable></literal>, except that
|
||||
<replaceable>e1</replaceable> is evaluated
|
||||
<emphasis>deeply</emphasis>: if it’s a list or set, its elements
|
||||
or attributes are also evaluated recursively.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><function>derivation</function>
|
||||
<replaceable>attrs</replaceable></term>
|
||||
|
||||
@@ -257,12 +274,28 @@ stdenv.mkDerivation {
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><function>builtins.fromJSON</function> <replaceable>e</replaceable></term>
|
||||
|
||||
<listitem><para>Convert a JSON string to a Nix
|
||||
value. For example,
|
||||
|
||||
<programlisting>
|
||||
builtins.fromJSON ''{"x": [1, 2, 3], "y": null}''
|
||||
</programlisting>
|
||||
|
||||
returns the value <literal>{ x = [ 1 2 3 ]; y = null;
|
||||
}</literal>. Floating point numbers are not
|
||||
supported.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><function>builtins.getAttr</function>
|
||||
<replaceable>s</replaceable> <replaceable>attrs</replaceable></term>
|
||||
<replaceable>s</replaceable> <replaceable>set</replaceable></term>
|
||||
|
||||
<listitem><para><function>getAttr</function> returns the attribute
|
||||
named <replaceable>s</replaceable> from the attribute set
|
||||
<replaceable>attrs</replaceable>. Evaluation aborts if the
|
||||
named <replaceable>s</replaceable> from
|
||||
<replaceable>set</replaceable>. Evaluation aborts if the
|
||||
attribute doesn’t exist. This is a dynamic version of the
|
||||
<literal>.</literal> operator, since <replaceable>s</replaceable>
|
||||
is an expression rather than an identifier.</para></listitem>
|
||||
@@ -289,15 +322,15 @@ stdenv.mkDerivation {
|
||||
|
||||
|
||||
<varlistentry><term><function>builtins.hasAttr</function>
|
||||
<replaceable>s</replaceable> <replaceable>attrs</replaceable></term>
|
||||
<replaceable>s</replaceable> <replaceable>set</replaceable></term>
|
||||
|
||||
<listitem><para><function>hasAttr</function> returns
|
||||
<literal>true</literal> if the attribute set
|
||||
<replaceable>attrs</replaceable> has an attribute named
|
||||
<replaceable>s</replaceable>, and <literal>false</literal>
|
||||
otherwise. This is a dynamic version of the <literal>?</literal>
|
||||
operator, since <replaceable>s</replaceable> is an expression
|
||||
rather than an identifier.</para></listitem>
|
||||
<literal>true</literal> if <replaceable>set</replaceable> has an
|
||||
attribute named <replaceable>s</replaceable>, and
|
||||
<literal>false</literal> otherwise. This is a dynamic version of
|
||||
the <literal>?</literal> operator, since
|
||||
<replaceable>s</replaceable> is an expression rather than an
|
||||
identifier.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
@@ -331,12 +364,12 @@ stdenv.mkDerivation {
|
||||
<listitem><para>Load, parse and return the Nix expression in the
|
||||
file <replaceable>path</replaceable>. If <replaceable>path
|
||||
</replaceable> is a directory, the file <filename>default.nix
|
||||
</filename> in that directory is loaded. Evaluation aborts if
|
||||
the file doesn’t exist or contains an incorrect Nix
|
||||
expression. <function>import</function> implements Nix’s module
|
||||
system: you can put any Nix expression (such as an attribute set
|
||||
or a function) in a separate file, and use it from Nix expressions
|
||||
in other files.</para>
|
||||
</filename> in that directory is loaded. Evaluation aborts if the
|
||||
file doesn’t exist or contains an incorrect Nix expression.
|
||||
<function>import</function> implements Nix’s module system: you
|
||||
can put any Nix expression (such as a set or a function) in a
|
||||
separate file, and use it from Nix expressions in other
|
||||
files.</para>
|
||||
|
||||
<para>A Nix expression loaded by <function>import</function> must
|
||||
not contain any <emphasis>free variables</emphasis> (identifiers
|
||||
@@ -383,9 +416,9 @@ x: x + 456</programlisting>
|
||||
<varlistentry><term><function>builtins.intersectAttrs</function>
|
||||
<replaceable>e1</replaceable> <replaceable>e2</replaceable></term>
|
||||
|
||||
<listitem><para>Return an attribute set consisting of the
|
||||
attributes in the set <replaceable>e2</replaceable> that also
|
||||
exist in the set <replaceable>e1</replaceable>.</para></listitem>
|
||||
<listitem><para>Return a set consisting of the attributes in the
|
||||
set <replaceable>e2</replaceable> that also exist in the set
|
||||
<replaceable>e1</replaceable>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
@@ -394,7 +427,7 @@ x: x + 456</programlisting>
|
||||
<replaceable>e</replaceable></term>
|
||||
|
||||
<listitem><para>Return <literal>true</literal> if
|
||||
<replaceable>e</replaceable> evaluates to an attribute set, and
|
||||
<replaceable>e</replaceable> evaluates to a set, and
|
||||
<literal>false</literal> otherwise.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
@@ -434,7 +467,7 @@ x: x + 456</programlisting>
|
||||
<replaceable>e</replaceable></term>
|
||||
|
||||
<listitem><para>Return <literal>true</literal> if
|
||||
<replaceable>e</replaceable> evaluates to a int, and
|
||||
<replaceable>e</replaceable> evaluates to an int, and
|
||||
<literal>false</literal> otherwise.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
@@ -490,9 +523,9 @@ x: x + 456</programlisting>
|
||||
<varlistentry><term><function>builtins.listToAttrs</function>
|
||||
<replaceable>e</replaceable></term>
|
||||
|
||||
<listitem><para>Construct an attribute set from a list specifying
|
||||
the names and values of each attribute. Each element of the list
|
||||
should be an attribute set consisting of a string-valued attribute
|
||||
<listitem><para>Construct a set from a list specifying the names
|
||||
and values of each attribute. Each element of the list should be
|
||||
a set consisting of a string-valued attribute
|
||||
<varname>name</varname> specifying the name of the attribute, and
|
||||
an attribute <varname>value</varname> specifying its value.
|
||||
Example:
|
||||
@@ -547,7 +580,7 @@ map (x: "foo" + x) [ "bar" "bla" "abc" ]</programlisting>
|
||||
a package name and version. The package name is everything up to
|
||||
but not including the first dash followed by a digit, and the
|
||||
version is everything following that dash. The result is returned
|
||||
in an attribute set <literal>{ name, version }</literal>. Thus,
|
||||
in a set <literal>{ name, version }</literal>. Thus,
|
||||
<literal>builtins.parseDrvName "nix-0.12pre12876"</literal>
|
||||
returns <literal>{ name = "nix"; version = "0.12pre12876";
|
||||
}</literal>.</para></listitem>
|
||||
@@ -579,13 +612,26 @@ in config.someSetting</programlisting>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<!--
|
||||
<varlistentry><term><function>relativise</function></term>
|
||||
<varlistentry><term><function>builtins.readDir</function>
|
||||
<replaceable>path</replaceable></term>
|
||||
|
||||
<listitem><para>TODO</para></listitem>
|
||||
<listitem><para>Return the contents of the directory
|
||||
<replaceable>path</replaceable> as a set mapping directory entries
|
||||
to the corresponding file type. For instance, if directory
|
||||
<filename>A</filename> contains a regular file
|
||||
<filename>B</filename> and another directory
|
||||
<filename>C</filename>, then <literal>builtins.readDir
|
||||
./A</literal> will return the set
|
||||
|
||||
<programlisting>
|
||||
{ A = "regular"; B = "directory"; }</programlisting>
|
||||
|
||||
The possible values for the file type are
|
||||
<literal>"regular"</literal>, <literal>"directory"</literal>,
|
||||
<literal>"symlink"</literal> and
|
||||
<literal>"unknown"</literal>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
-->
|
||||
|
||||
|
||||
<varlistentry><term><function>builtins.readFile</function>
|
||||
@@ -598,21 +644,32 @@ in config.someSetting</programlisting>
|
||||
|
||||
|
||||
<varlistentry><term><function>removeAttrs</function>
|
||||
<replaceable>attrs</replaceable> <replaceable>list</replaceable></term>
|
||||
<replaceable>set</replaceable> <replaceable>list</replaceable></term>
|
||||
|
||||
<listitem><para>Remove the attributes listed in
|
||||
<replaceable>list</replaceable> from the attribute set
|
||||
<replaceable>attrs</replaceable>. The attributes don’t have to
|
||||
exist in <replaceable>attrs</replaceable>. For instance,
|
||||
<replaceable>list</replaceable> from
|
||||
<replaceable>set</replaceable>. The attributes don’t have to
|
||||
exist in <replaceable>set</replaceable>. For instance,
|
||||
|
||||
<screen>
|
||||
removeAttrs { x = 1; y = 2; z = 3; } [ "a" "x" "z" ]</screen>
|
||||
<programlisting>
|
||||
removeAttrs { x = 1; y = 2; z = 3; } [ "a" "x" "z" ]</programlisting>
|
||||
|
||||
evaluates to <literal>{ y = 2; }</literal>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><function>builtins.seq</function>
|
||||
<replaceable>e1</replaceable> <replaceable>e2</replaceable></term>
|
||||
|
||||
<listitem><para>Evaluate <replaceable>e1</replaceable>, then
|
||||
evaluate and return <replaceable>e2</replaceable>. This ensures
|
||||
that a computation is strict in the value of
|
||||
<replaceable>e1</replaceable>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><function>builtins.stringLength</function>
|
||||
<replaceable>e</replaceable></term>
|
||||
|
||||
@@ -750,6 +807,19 @@ in foo</programlisting>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><function>builtins.toJSON</function> <replaceable>e</replaceable></term>
|
||||
|
||||
<listitem><para>Return a string containing a JSON representation
|
||||
of <replaceable>e</replaceable>. Strings, integers, booleans,
|
||||
nulls and lists are mapped to their JSON equivalents. Sets
|
||||
(except derivations) are represented as objects. Derivations are
|
||||
translated to a JSON string containing the derivation’s output
|
||||
path. Paths are copied to the store and represented as a JSON
|
||||
string of the resulting store path.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><function>builtins.toPath</function> <replaceable>s</replaceable></term>
|
||||
|
||||
<listitem><para>Convert the string value
|
||||
@@ -792,7 +862,7 @@ in foo</programlisting>
|
||||
servlet container</link>. A servlet container contains a number
|
||||
of servlets (<filename>*.war</filename> files) each exported under
|
||||
a specific URI prefix. So the servlet configuration is a list of
|
||||
attribute sets containing the <varname>path</varname> and
|
||||
sets containing the <varname>path</varname> and
|
||||
<varname>war</varname> of the servlet (<xref
|
||||
linkend='ex-toxml-co-servlets' />). This kind of information is
|
||||
difficult to communicate with the normal method of passing
|
||||
@@ -901,6 +971,19 @@ stdenv.mkDerivation (rec {
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><function>builtins.typeOf</function>
|
||||
<replaceable>e</replaceable></term>
|
||||
|
||||
<listitem><para>Return a string representing the type of the value
|
||||
<replaceable>e</replaceable>, namely <literal>"int"</literal>,
|
||||
<literal>"bool"</literal>, <literal>"string"</literal>,
|
||||
<literal>"path"</literal>, <literal>"null"</literal>,
|
||||
<literal>"set"</literal>, <literal>"list"</literal> or
|
||||
<literal>"lambda"</literal>.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
|
||||
</variablelist>
|
||||
|
||||
|
||||
@@ -0,0 +1,34 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-debug-build">
|
||||
|
||||
<title>Debugging Build Failures</title>
|
||||
|
||||
<para>At the beginning of each phase of the build (such as unpacking,
|
||||
building or installing), the set of all shell variables is written to
|
||||
the file <filename>env-vars</filename> at the top-level build
|
||||
directory. This is useful for debugging: it allows you to recreate
|
||||
the environment in which a build was performed. For instance, if a
|
||||
build fails, then assuming you used the <option>-K</option> flag, you
|
||||
can go to the output directory and <quote>switch</quote> to the
|
||||
environment of the builder:
|
||||
|
||||
<screen>
|
||||
$ nix-build -K ./foo.nix
|
||||
... fails, keeping build directory `/tmp/nix-1234-0'
|
||||
|
||||
$ cd /tmp/nix-1234-0
|
||||
|
||||
$ source env-vars
|
||||
|
||||
<lineannotation>(edit some files...)</lineannotation>
|
||||
|
||||
$ make
|
||||
|
||||
<lineannotation>(execution continues with the same GCC, make, etc.)</lineannotation></screen>
|
||||
|
||||
</para>
|
||||
|
||||
</section>
|
||||
@@ -0,0 +1,211 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ssec-derivation">
|
||||
|
||||
<title>Derivations</title>
|
||||
|
||||
<para>The most important built-in function is
|
||||
<function>derivation</function>, which is used to describe a single
|
||||
derivation (a build action). It takes as input a set, the attributes
|
||||
of which specify the inputs of the build.</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem xml:id="attr-system"><para>There must be an attribute named
|
||||
<varname>system</varname> whose value must be a string specifying a
|
||||
Nix platform identifier, such as <literal>"i686-linux"</literal> or
|
||||
<literal>"powerpc-darwin"</literal><footnote><para>To figure out
|
||||
your platform identifier, look at the line <quote>Checking for the
|
||||
canonical Nix system name</quote> in the output of Nix's
|
||||
<filename>configure</filename> script.</para></footnote> The build
|
||||
can only be performed on a machine and operating system matching the
|
||||
platform identifier. (Nix can automatically forward builds for
|
||||
other platforms by forwarding them to other machines; see <xref
|
||||
linkend='chap-distributed-builds' />.)</para></listitem>
|
||||
|
||||
<listitem><para>There must be an attribute named
|
||||
<varname>name</varname> whose value must be a string. This is used
|
||||
as a symbolic name for the package by <command>nix-env</command>,
|
||||
and it is appended to the output paths of the
|
||||
derivation.</para></listitem>
|
||||
|
||||
<listitem><para>There must be an attribute named
|
||||
<varname>builder</varname> that identifies the program that is
|
||||
executed to perform the build. It can be either a derivation or a
|
||||
source (a local file reference, e.g.,
|
||||
<filename>./builder.sh</filename>).</para></listitem>
|
||||
|
||||
<listitem><para>Every attribute is passed as an environment variable
|
||||
to the builder. Attribute values are translated to environment
|
||||
variables as follows:
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para>Strings and integers are just passed
|
||||
verbatim.</para></listitem>
|
||||
|
||||
<listitem><para>A <emphasis>path</emphasis> (e.g.,
|
||||
<filename>../foo/sources.tar</filename>) causes the referenced
|
||||
file to be copied to the store; its location in the store is put
|
||||
in the environment variable. The idea is that all sources
|
||||
should reside in the Nix store, since all inputs to a derivation
|
||||
should reside in the Nix store.</para></listitem>
|
||||
|
||||
<listitem><para>A <emphasis>derivation</emphasis> causes that
|
||||
derivation to be built prior to the present derivation; its
|
||||
default output path is put in the environment
|
||||
variable.</para></listitem>
|
||||
|
||||
<listitem><para>Lists of the previous types are also allowed.
|
||||
They are simply concatenated, separated by
|
||||
spaces.</para></listitem>
|
||||
|
||||
<listitem><para><literal>true</literal> is passed as the string
|
||||
<literal>1</literal>, <literal>false</literal> and
|
||||
<literal>null</literal> are passed as an empty string.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>The optional attribute <varname>args</varname>
|
||||
specifies command-line arguments to be passed to the builder. It
|
||||
should be a list.</para></listitem>
|
||||
|
||||
<listitem><para>The optional attribute <varname>outputs</varname>
|
||||
specifies a list of symbolic outputs of the derivation. By default,
|
||||
a derivation produces a single output path, denoted as
|
||||
<literal>out</literal>. However, derivations can produce multiple
|
||||
output paths. This is useful because it allows outputs to be
|
||||
downloaded or garbage-collected separately. For instance, imagine a
|
||||
library package that provides a dynamic library, header files, and
|
||||
documentation. A program that links against the library doesn’t
|
||||
need the header files and documentation at runtime, and it doesn’t
|
||||
need the documentation at build time. Thus, the library package
|
||||
could specify:
|
||||
<programlisting>
|
||||
outputs = [ "lib" "headers" "doc" ];
|
||||
</programlisting>
|
||||
This will cause Nix to pass environment variables
|
||||
<literal>lib</literal>, <literal>headers</literal> and
|
||||
<literal>doc</literal> to the builder containing the intended store
|
||||
paths of each output. The builder would typically do something like
|
||||
<programlisting>
|
||||
./configure --libdir=$lib/lib --includedir=$headers/include --docdir=$doc/share/doc
|
||||
</programlisting>
|
||||
for an Autoconf-style package. You can refer to each output of a
|
||||
derivation by selecting it as an attribute, e.g.
|
||||
<programlisting>
|
||||
buildInputs = [ pkg.lib pkg.headers ];
|
||||
</programlisting>
|
||||
The first element of <varname>output</varname> determines the
|
||||
<emphasis>default output</emphasis>. Thus, you could also write
|
||||
<programlisting>
|
||||
buildInputs = [ pkg pkg.headers ];
|
||||
</programlisting>
|
||||
since <literal>pkg</literal> is equivalent to
|
||||
<literal>pkg.lib</literal>.</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
<para>The function <function>mkDerivation</function> in the Nixpkgs
|
||||
standard environment is a wrapper around
|
||||
<function>derivation</function> that adds a default value for
|
||||
<varname>system</varname> and always uses Bash as the builder, to
|
||||
which the supplied builder is passed as a command-line argument. See
|
||||
the Nixpkgs manual for details.</para>
|
||||
|
||||
<para>The builder is executed as follows:
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para>A temporary directory is created under the directory
|
||||
specified by <envar>TMPDIR</envar> (default
|
||||
<filename>/tmp</filename>) where the build will take place. The
|
||||
current directory is changed to this directory.</para></listitem>
|
||||
|
||||
<listitem><para>The environment is cleared and set to the derivation
|
||||
attributes, as specified above.</para></listitem>
|
||||
|
||||
<listitem><para>In addition, the following variables are set:
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para><envar>NIX_BUILD_TOP</envar> contains the path of
|
||||
the temporary directory for this build.</para></listitem>
|
||||
|
||||
<listitem><para>Also, <envar>TMPDIR</envar>,
|
||||
<envar>TEMPDIR</envar>, <envar>TMP</envar>, <envar>TEMP</envar>
|
||||
are set to point to the temporary directory. This is to prevent
|
||||
the builder from accidentally writing temporary files anywhere
|
||||
else. Doing so might cause interference by other
|
||||
processes.</para></listitem>
|
||||
|
||||
<listitem><para><envar>PATH</envar> is set to
|
||||
<filename>/path-not-set</filename> to prevent shells from
|
||||
initialising it to their built-in default value.</para></listitem>
|
||||
|
||||
<listitem><para><envar>HOME</envar> is set to
|
||||
<filename>/homeless-shelter</filename> to prevent programs from
|
||||
using <filename>/etc/passwd</filename> or the like to find the
|
||||
user's home directory, which could cause impurity. Usually, when
|
||||
<envar>HOME</envar> is set, it is used as the location of the home
|
||||
directory, even if it points to a non-existent
|
||||
path.</para></listitem>
|
||||
|
||||
<listitem><para><envar>NIX_STORE</envar> is set to the path of the
|
||||
top-level Nix store directory (typically,
|
||||
<filename>/nix/store</filename>).</para></listitem>
|
||||
|
||||
<listitem><para>For each output declared in
|
||||
<varname>outputs</varname>, the corresponding environment variable
|
||||
is set to point to the intended path in the Nix store for that
|
||||
output. Each output path is a concatenation of the cryptographic
|
||||
hash of all build inputs, the <varname>name</varname> attribute
|
||||
and the output name. (The output name is omitted if it’s
|
||||
<literal>out</literal>.)</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>If an output path already exists, it is removed.
|
||||
Also, locks are acquired to prevent multiple Nix instances from
|
||||
performing the same build at the same time.</para></listitem>
|
||||
|
||||
<listitem><para>A log of the combined standard output and error is
|
||||
written to <filename>/nix/var/log/nix</filename>.</para></listitem>
|
||||
|
||||
<listitem><para>The builder is executed with the arguments specified
|
||||
by the attribute <varname>args</varname>. If it exits with exit
|
||||
code 0, it is considered to have succeeded.</para></listitem>
|
||||
|
||||
<listitem><para>The temporary directory is removed (unless the
|
||||
<option>-K</option> option was specified).</para></listitem>
|
||||
|
||||
<listitem><para>If the build was successful, Nix scans each output
|
||||
path for references to input paths by looking for the hash parts of
|
||||
the input paths. Since these are potential runtime dependencies,
|
||||
Nix registers them as dependencies of the output
|
||||
paths.</para></listitem>
|
||||
|
||||
<listitem><para>After the build, Nix sets the last-modified
|
||||
timestamp on all files in the build result to 1 (00:00:01 1/1/1970
|
||||
UTC), sets the group to the default group, and sets the mode of the
|
||||
file to 0444 or 0555 (i.e., read-only, with execute permission
|
||||
enabled if the file was originally executable). Note that possible
|
||||
<literal>setuid</literal> and <literal>setgid</literal> bits are
|
||||
cleared. Setuid and setgid programs are not currently supported by
|
||||
Nix. This is because the Nix archives used in deployment have no
|
||||
concept of ownership information, and because it makes the build
|
||||
result dependent on the user performing the build.</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</para>
|
||||
|
||||
<xi:include href="advanced-attributes.xml" />
|
||||
|
||||
</section>
|
||||
@@ -0,0 +1,30 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-expression-language">
|
||||
|
||||
<title>Nix Expression Language</title>
|
||||
|
||||
<para>The Nix expression language is a pure, lazy, functional
|
||||
language. Purity means that operations in the language don't have
|
||||
side-effects (for instance, there is no variable assignment).
|
||||
Laziness means that arguments to functions are evaluated only when
|
||||
they are needed. Functional means that functions are
|
||||
<quote>normal</quote> values that can be passed around and manipulated
|
||||
in interesting ways. The language is not a full-featured, general
|
||||
purpose language. Its main job is to describe packages,
|
||||
compositions of packages, and the variability within
|
||||
packages.</para>
|
||||
|
||||
<para>This section presents the various features of the
|
||||
language.</para>
|
||||
|
||||
<xi:include href="language-values.xml" />
|
||||
<xi:include href="language-constructs.xml" />
|
||||
<xi:include href="language-operators.xml" />
|
||||
<xi:include href="derivations.xml" />
|
||||
<xi:include href="builtins.xml" />
|
||||
|
||||
|
||||
</chapter>
|
||||
@@ -0,0 +1,148 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='sec-expression-syntax'>
|
||||
|
||||
<title>Expression Syntax</title>
|
||||
|
||||
<example xml:id='ex-hello-nix'><title>Nix expression for GNU Hello
|
||||
(<filename>default.nix</filename>)</title>
|
||||
<programlisting>
|
||||
{ stdenv, fetchurl, perl }: <co xml:id='ex-hello-nix-co-1' />
|
||||
|
||||
stdenv.mkDerivation { <co xml:id='ex-hello-nix-co-2' />
|
||||
name = "hello-2.1.1"; <co xml:id='ex-hello-nix-co-3' />
|
||||
builder = ./builder.sh; <co xml:id='ex-hello-nix-co-4' />
|
||||
src = fetchurl { <co xml:id='ex-hello-nix-co-5' />
|
||||
url = ftp://ftp.nluug.nl/pub/gnu/hello/hello-2.1.1.tar.gz;
|
||||
md5 = "70c9ccf9fac07f762c24f2df2290784d";
|
||||
};
|
||||
inherit perl; <co xml:id='ex-hello-nix-co-6' />
|
||||
}</programlisting>
|
||||
</example>
|
||||
|
||||
<para><xref linkend='ex-hello-nix' /> shows a Nix expression for GNU
|
||||
Hello. It's actually already in the Nix Packages collection in
|
||||
<filename>pkgs/applications/misc/hello/ex-1/default.nix</filename>.
|
||||
It is customary to place each package in a separate directory and call
|
||||
the single Nix expression in that directory
|
||||
<filename>default.nix</filename>. The file has the following elements
|
||||
(referenced from the figure by number):
|
||||
|
||||
<calloutlist>
|
||||
|
||||
<callout arearefs='ex-hello-nix-co-1'>
|
||||
|
||||
<para>This states that the expression is a
|
||||
<emphasis>function</emphasis> that expects to be called with three
|
||||
arguments: <varname>stdenv</varname>, <varname>fetchurl</varname>,
|
||||
and <varname>perl</varname>. They are needed to build Hello, but
|
||||
we don't know how to build them here; that's why they are function
|
||||
arguments. <varname>stdenv</varname> is a package that is used
|
||||
by almost all Nix Packages packages; it provides a
|
||||
<quote>standard</quote> environment consisting of the things you
|
||||
would expect in a basic Unix environment: a C/C++ compiler (GCC,
|
||||
to be precise), the Bash shell, fundamental Unix tools such as
|
||||
<command>cp</command>, <command>grep</command>,
|
||||
<command>tar</command>, etc. <varname>fetchurl</varname> is a
|
||||
function that downloads files. <varname>perl</varname> is the
|
||||
Perl interpreter.</para>
|
||||
|
||||
<para>Nix functions generally have the form <literal>{ x, y, ...,
|
||||
z }: e</literal> where <varname>x</varname>, <varname>y</varname>,
|
||||
etc. are the names of the expected arguments, and where
|
||||
<replaceable>e</replaceable> is the body of the function. So
|
||||
here, the entire remainder of the file is the body of the
|
||||
function; when given the required arguments, the body should
|
||||
describe how to build an instance of the Hello package.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-nix-co-2'>
|
||||
|
||||
<para>So we have to build a package. Building something from
|
||||
other stuff is called a <emphasis>derivation</emphasis> in Nix (as
|
||||
opposed to sources, which are built by humans instead of
|
||||
computers). We perform a derivation by calling
|
||||
<varname>stdenv.mkDerivation</varname>.
|
||||
<varname>mkDerivation</varname> is a function provided by
|
||||
<varname>stdenv</varname> that builds a package from a set of
|
||||
<emphasis>attributes</emphasis>. A set is just a list of
|
||||
key/value pairs where each key is a string and each value is an
|
||||
arbitrary Nix expression. They take the general form <literal>{
|
||||
<replaceable>name1</replaceable> =
|
||||
<replaceable>expr1</replaceable>; <replaceable>...</replaceable>
|
||||
<replaceable>nameN</replaceable> =
|
||||
<replaceable>exprN</replaceable>; }</literal>.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-nix-co-3'>
|
||||
|
||||
<para>The attribute <varname>name</varname> specifies the symbolic
|
||||
name and version of the package. Nix doesn't really care about
|
||||
these things, but they are used by for instance <command>nix-env
|
||||
-q</command> to show a <quote>human-readable</quote> name for
|
||||
packages. This attribute is required by
|
||||
<varname>mkDerivation</varname>.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-nix-co-4'>
|
||||
|
||||
<para>The attribute <varname>builder</varname> specifies the
|
||||
builder. This attribute can sometimes be omitted, in which case
|
||||
<varname>mkDerivation</varname> will fill in a default builder
|
||||
(which does a <literal>configure; make; make install</literal>, in
|
||||
essence). Hello is sufficiently simple that the default builder
|
||||
would suffice, but in this case, we will show an actual builder
|
||||
for educational purposes. The value
|
||||
<command>./builder.sh</command> refers to the shell script shown
|
||||
in <xref linkend='ex-hello-builder' />, discussed below.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-nix-co-5'>
|
||||
|
||||
<para>The builder has to know what the sources of the package
|
||||
are. Here, the attribute <varname>src</varname> is bound to the
|
||||
result of a call to the <command>fetchurl</command> function.
|
||||
Given a URL and an MD5 hash of the expected contents of the file
|
||||
at that URL, this function builds a derivation that downloads the
|
||||
file and checks its hash. So the sources are a dependency that
|
||||
like all other dependencies is built before Hello itself is
|
||||
built.</para>
|
||||
|
||||
<para>Instead of <varname>src</varname> any other name could have
|
||||
been used, and in fact there can be any number of sources (bound
|
||||
to different attributes). However, <varname>src</varname> is
|
||||
customary, and it's also expected by the default builder (which we
|
||||
don't use in this example).</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-nix-co-6'>
|
||||
|
||||
<para>Since the derivation requires Perl, we have to pass the
|
||||
value of the <varname>perl</varname> function argument to the
|
||||
builder. All attributes in the set are actually passed as
|
||||
environment variables to the builder, so declaring an attribute
|
||||
|
||||
<programlisting>
|
||||
perl = perl;</programlisting>
|
||||
|
||||
will do the trick: it binds an attribute <varname>perl</varname>
|
||||
to the function argument which also happens to be called
|
||||
<varname>perl</varname>. However, it looks a bit silly, so there
|
||||
is a shorter syntax. The <literal>inherit</literal> keyword
|
||||
causes the specified attributes to be bound to whatever variables
|
||||
with the same name happen to be in scope.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
</calloutlist>
|
||||
|
||||
</para>
|
||||
|
||||
</section>
|
||||
@@ -0,0 +1,98 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='sec-generic-builder'>
|
||||
|
||||
<title>Generic Builder Syntax</title>
|
||||
|
||||
<para>Recall from <xref linkend='ex-hello-builder' /> that the builder
|
||||
looked something like this:
|
||||
|
||||
<programlisting>
|
||||
PATH=$perl/bin:$PATH
|
||||
tar xvfz $src
|
||||
cd hello-*
|
||||
./configure --prefix=$out
|
||||
make
|
||||
make install</programlisting>
|
||||
|
||||
The builders for almost all Unix packages look like this — set up some
|
||||
environment variables, unpack the sources, configure, build, and
|
||||
install. For this reason the standard environment provides some Bash
|
||||
functions that automate the build process. A builder using the
|
||||
generic build facilities in shown in <xref linkend='ex-hello-builder2'
|
||||
/>.</para>
|
||||
|
||||
<example xml:id='ex-hello-builder2'><title>Build script using the generic
|
||||
build functions</title>
|
||||
<programlisting>
|
||||
buildInputs="$perl" <co xml:id='ex-hello-builder2-co-1' />
|
||||
|
||||
source $stdenv/setup <co xml:id='ex-hello-builder2-co-2' />
|
||||
|
||||
genericBuild <co xml:id='ex-hello-builder2-co-3' /></programlisting>
|
||||
</example>
|
||||
|
||||
<calloutlist>
|
||||
|
||||
<callout arearefs='ex-hello-builder2-co-1'>
|
||||
|
||||
<para>The <envar>buildInputs</envar> variable tells
|
||||
<filename>setup</filename> to use the indicated packages as
|
||||
<quote>inputs</quote>. This means that if a package provides a
|
||||
<filename>bin</filename> subdirectory, it's added to
|
||||
<envar>PATH</envar>; if it has a <filename>include</filename>
|
||||
subdirectory, it's added to GCC's header search path; and so
|
||||
on.<footnote><para>How does it work? <filename>setup</filename>
|
||||
tries to source the file
|
||||
<filename><replaceable>pkg</replaceable>/nix-support/setup-hook</filename>
|
||||
of all dependencies. These “setup hooks” can then set up whatever
|
||||
environment variables they want; for instance, the setup hook for
|
||||
Perl sets the <envar>PERL5LIB</envar> environment variable to
|
||||
contain the <filename>lib/site_perl</filename> directories of all
|
||||
inputs.</para></footnote>
|
||||
</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder2-co-2'>
|
||||
|
||||
<para>The function <function>genericBuild</function> is defined in
|
||||
the file <literal>$stdenv/setup</literal>.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-hello-builder2-co-3'>
|
||||
|
||||
<para>The final step calls the shell function
|
||||
<function>genericBuild</function>, which performs the steps that
|
||||
were done explicitly in <xref linkend='ex-hello-builder' />. The
|
||||
generic builder is smart enough to figure out whether to unpack
|
||||
the sources using <command>gzip</command>,
|
||||
<command>bzip2</command>, etc. It can be customised in many ways;
|
||||
see the Nixpkgs manual for details.</para>
|
||||
|
||||
</callout>
|
||||
|
||||
</calloutlist>
|
||||
|
||||
<para>Discerning readers will note that the
|
||||
<envar>buildInputs</envar> could just as well have been set in the Nix
|
||||
expression, like this:
|
||||
|
||||
<programlisting>
|
||||
buildInputs = [ perl ];</programlisting>
|
||||
|
||||
The <varname>perl</varname> attribute can then be removed, and the
|
||||
builder becomes even shorter:
|
||||
|
||||
<programlisting>
|
||||
source $stdenv/setup
|
||||
genericBuild</programlisting>
|
||||
|
||||
In fact, <varname>mkDerivation</varname> provides a default builder
|
||||
that looks exactly like that, so it is actually possible to omit the
|
||||
builder for Hello entirely.</para>
|
||||
|
||||
</section>
|
||||
@@ -0,0 +1,362 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-constructs">
|
||||
|
||||
<title>Language Constructs</title>
|
||||
|
||||
<simplesect><title>Recursive sets</title>
|
||||
|
||||
<para>Recursive sets are just normal sets, but the attributes can
|
||||
refer to each other. For example,
|
||||
|
||||
<programlisting>
|
||||
rec {
|
||||
x = y;
|
||||
y = 123;
|
||||
}.x
|
||||
</programlisting>
|
||||
|
||||
evaluates to <literal>123</literal>. Note that without
|
||||
<literal>rec</literal> the binding <literal>x = y;</literal> would
|
||||
refer to the variable <varname>y</varname> in the surrounding scope,
|
||||
if one exists, and would be invalid if no such variable exists. That
|
||||
is, in a normal (non-recursive) set, attributes are not added to the
|
||||
lexical scope; in a recursive set, they are.</para>
|
||||
|
||||
<para>Recursive sets of course introduce the danger of infinite
|
||||
recursion. For example,
|
||||
|
||||
<programlisting>
|
||||
rec {
|
||||
x = y;
|
||||
y = x;
|
||||
}.x</programlisting>
|
||||
|
||||
does not terminate<footnote><para>Actually, Nix detects infinite
|
||||
recursion in this case and aborts (<quote>infinite recursion
|
||||
encountered</quote>).</para></footnote>.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Let-expressions</title>
|
||||
|
||||
<para>A let-expression allows you define local variables for an
|
||||
expression. For instance,
|
||||
|
||||
<programlisting>
|
||||
let
|
||||
x = "foo";
|
||||
y = "bar";
|
||||
in x + y</programlisting>
|
||||
|
||||
evaluates to <literal>"foobar"</literal>.
|
||||
|
||||
</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Inheriting attributes</title>
|
||||
|
||||
<para>When defining a set it is often convenient to copy variables
|
||||
from the surrounding lexical scope (e.g., when you want to propagate
|
||||
attributes). This can be shortened using the
|
||||
<literal>inherit</literal> keyword. For instance,
|
||||
|
||||
<programlisting>
|
||||
let x = 123; in
|
||||
{ inherit x;
|
||||
y = 456;
|
||||
}</programlisting>
|
||||
|
||||
evaluates to <literal>{ x = 123; y = 456; }</literal>. (Note that
|
||||
this works because <varname>x</varname> is added to the lexical scope
|
||||
by the <literal>let</literal> construct.) It is also possible to
|
||||
inherit attributes from another set. For instance, in this fragment
|
||||
from <filename>all-packages.nix</filename>,
|
||||
|
||||
<programlisting>
|
||||
graphviz = (import ../tools/graphics/graphviz) {
|
||||
inherit fetchurl stdenv libpng libjpeg expat x11 yacc;
|
||||
inherit (xlibs) libXaw;
|
||||
};
|
||||
|
||||
xlibs = {
|
||||
libX11 = ...;
|
||||
libXaw = ...;
|
||||
...
|
||||
}
|
||||
|
||||
libpng = ...;
|
||||
libjpg = ...;
|
||||
...</programlisting>
|
||||
|
||||
the set used in the function call to the function defined in
|
||||
<filename>../tools/graphics/graphviz</filename> inherits a number of
|
||||
variables from the surrounding scope (<varname>fetchurl</varname>
|
||||
... <varname>yacc</varname>), but also inherits
|
||||
<varname>libXaw</varname> (the X Athena Widgets) from the
|
||||
<varname>xlibs</varname> (X11 client-side libraries) set.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect xml:id="ss-functions"><title>Functions</title>
|
||||
|
||||
<para>Functions have the following form:
|
||||
|
||||
<programlisting>
|
||||
<replaceable>pattern</replaceable>: <replaceable>body</replaceable></programlisting>
|
||||
|
||||
The pattern specifies what the argument of the function must look
|
||||
like, and binds variables in the body to (parts of) the
|
||||
argument. There are three kinds of patterns:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
|
||||
<listitem><para>If a pattern is a single identifier, then the
|
||||
function matches any argument. Example:
|
||||
|
||||
<programlisting>
|
||||
let negate = x: !x;
|
||||
concat = x: y: x + y;
|
||||
in if negate true then concat "foo" "bar" else ""</programlisting>
|
||||
|
||||
Note that <function>concat</function> is a function that takes one
|
||||
argument and returns a function that takes another argument. This
|
||||
allows partial parameterisation (i.e., only filling some of the
|
||||
arguments of a function); e.g.,
|
||||
|
||||
<programlisting>
|
||||
map (concat "foo") [ "bar" "bla" "abc" ]</programlisting>
|
||||
|
||||
evaluates to <literal>[ "foobar" "foobla"
|
||||
"fooabc" ]</literal>.</para></listitem>
|
||||
|
||||
|
||||
<listitem><para>A <emphasis>set pattern</emphasis> of the form
|
||||
<literal>{ name1, name2, …, nameN }</literal> matches a set
|
||||
containing the listed attributes, and binds the values of those
|
||||
attributes to variables in the function body. For example, the
|
||||
function
|
||||
|
||||
<programlisting>
|
||||
{ x, y, z }: z + y + x</programlisting>
|
||||
|
||||
can only be called with a set containing exactly the attributes
|
||||
<varname>x</varname>, <varname>y</varname> and
|
||||
<varname>z</varname>. No other attributes are allowed. If you want
|
||||
to allow additional arguments, you can use an ellipsis
|
||||
(<literal>...</literal>):
|
||||
|
||||
<programlisting>
|
||||
{ x, y, z, ... }: z + y + x</programlisting>
|
||||
|
||||
This works on any set that contains at least the three named
|
||||
attributes.</para>
|
||||
|
||||
<para>It is possible to provide <emphasis>default values</emphasis>
|
||||
for attributes, in which case they are allowed to be missing. A
|
||||
default value is specified by writing
|
||||
<literal><replaceable>name</replaceable> ?
|
||||
<replaceable>e</replaceable></literal>, where
|
||||
<replaceable>e</replaceable> is an arbitrary expression. For example,
|
||||
|
||||
<programlisting>
|
||||
{ x, y ? "foo", z ? "bar" }: z + y + x</programlisting>
|
||||
|
||||
specifies a function that only requires an attribute named
|
||||
<varname>x</varname>, but optionally accepts <varname>y</varname>
|
||||
and <varname>z</varname>.</para></listitem>
|
||||
|
||||
|
||||
<listitem><para>An <literal>@</literal>-pattern provides a means of referring
|
||||
to the whole value being matched:
|
||||
|
||||
<programlisting>
|
||||
args@{ x, y, z, ... }: z + y + x + args.a</programlisting>
|
||||
|
||||
Here <varname>args</varname> is bound to the entire argument, which
|
||||
is further matched against the pattern <literal>{ x, y, z,
|
||||
... }</literal>.</para></listitem>
|
||||
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
<para>Note that functions do not have names. If you want to give them
|
||||
a name, you can bind them to an attribute, e.g.,
|
||||
|
||||
<programlisting>
|
||||
let concat = { x, y }: x + y;
|
||||
in concat { x = "foo"; y = "bar"; }</programlisting>
|
||||
|
||||
</para>
|
||||
|
||||
<para>A set that has a <literal>__functor</literal> attribute whose value
|
||||
is callable (i.e. is itself a function or a set with a
|
||||
<literal>__functor</literal> attribute whose value is callable) can be
|
||||
applied as if it were a function, with the set itself passed in first
|
||||
, e.g.,
|
||||
|
||||
<programlisting>
|
||||
let add = { __functor = self: x: x + self.x; };
|
||||
inc = add // { x = 1; };
|
||||
in inc 1
|
||||
</programlisting>
|
||||
|
||||
evaluates to <literal>2</literal>. This can be used to attach metadata to a
|
||||
function without the caller needing to treat it specially, or to implement
|
||||
a form of object-oriented programming, for example.
|
||||
|
||||
</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Conditionals</title>
|
||||
|
||||
<para>Conditionals look like this:
|
||||
|
||||
<programlisting>
|
||||
if <replaceable>e1</replaceable> then <replaceable>e2</replaceable> else <replaceable>e3</replaceable></programlisting>
|
||||
|
||||
where <replaceable>e1</replaceable> is an expression that should
|
||||
evaluate to a Boolean value (<literal>true</literal> or
|
||||
<literal>false</literal>).</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Assertions</title>
|
||||
|
||||
<para>Assertions are generally used to check that certain requirements
|
||||
on or between features and dependencies hold. They look like this:
|
||||
|
||||
<programlisting>
|
||||
assert <replaceable>e1</replaceable>; <replaceable>e2</replaceable></programlisting>
|
||||
|
||||
where <replaceable>e1</replaceable> is an expression that should
|
||||
evaluate to a Boolean value. If it evaluates to
|
||||
<literal>true</literal>, <replaceable>e2</replaceable> is returned;
|
||||
otherwise expression evaluation is aborted and a backtrace is printed.</para>
|
||||
|
||||
<example xml:id='ex-subversion-nix'><title>Nix expression for Subversion</title>
|
||||
<programlisting>
|
||||
{ localServer ? false
|
||||
, httpServer ? false
|
||||
, sslSupport ? false
|
||||
, pythonBindings ? false
|
||||
, javaSwigBindings ? false
|
||||
, javahlBindings ? false
|
||||
, stdenv, fetchurl
|
||||
, openssl ? null, httpd ? null, db4 ? null, expat, swig ? null, j2sdk ? null
|
||||
}:
|
||||
|
||||
assert localServer -> db4 != null; <co xml:id='ex-subversion-nix-co-1' />
|
||||
assert httpServer -> httpd != null && httpd.expat == expat; <co xml:id='ex-subversion-nix-co-2' />
|
||||
assert sslSupport -> openssl != null && (httpServer -> httpd.openssl == openssl); <co xml:id='ex-subversion-nix-co-3' />
|
||||
assert pythonBindings -> swig != null && swig.pythonSupport;
|
||||
assert javaSwigBindings -> swig != null && swig.javaSupport;
|
||||
assert javahlBindings -> j2sdk != null;
|
||||
|
||||
stdenv.mkDerivation {
|
||||
name = "subversion-1.1.1";
|
||||
...
|
||||
openssl = if sslSupport then openssl else null; <co xml:id='ex-subversion-nix-co-4' />
|
||||
...
|
||||
}</programlisting>
|
||||
</example>
|
||||
|
||||
<para><xref linkend='ex-subversion-nix' /> show how assertions are
|
||||
used in the Nix expression for Subversion.</para>
|
||||
|
||||
<calloutlist>
|
||||
|
||||
<callout arearefs='ex-subversion-nix-co-1'>
|
||||
<para>This assertion states that if Subversion is to have support
|
||||
for local repositories, then Berkeley DB is needed. So if the
|
||||
Subversion function is called with the
|
||||
<varname>localServer</varname> argument set to
|
||||
<literal>true</literal> but the <varname>db4</varname> argument
|
||||
set to <literal>null</literal>, then the evaluation fails.</para>
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-subversion-nix-co-2'>
|
||||
<para>This is a more subtle condition: if Subversion is built with
|
||||
Apache (<literal>httpServer</literal>) support, then the Expat
|
||||
library (an XML library) used by Subversion should be same as the
|
||||
one used by Apache. This is because in this configuration
|
||||
Subversion code ends up being linked with Apache code, and if the
|
||||
Expat libraries do not match, a build- or runtime link error or
|
||||
incompatibility might occur.</para>
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-subversion-nix-co-3'>
|
||||
<para>This assertion says that in order for Subversion to have SSL
|
||||
support (so that it can access <literal>https</literal> URLs), an
|
||||
OpenSSL library must be passed. Additionally, it says that
|
||||
<emphasis>if</emphasis> Apache support is enabled, then Apache's
|
||||
OpenSSL should match Subversion's. (Note that if Apache support
|
||||
is not enabled, we don't care about Apache's OpenSSL.)</para>
|
||||
</callout>
|
||||
|
||||
<callout arearefs='ex-subversion-nix-co-4'>
|
||||
<para>The conditional here is not really related to assertions,
|
||||
but is worth pointing out: it ensures that if SSL support is
|
||||
disabled, then the Subversion derivation is not dependent on
|
||||
OpenSSL, even if a non-<literal>null</literal> value was passed.
|
||||
This prevents an unnecessary rebuild of Subversion if OpenSSL
|
||||
changes.</para>
|
||||
</callout>
|
||||
|
||||
</calloutlist>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
|
||||
<simplesect><title>With-expressions</title>
|
||||
|
||||
<para>A <emphasis>with-expression</emphasis>,
|
||||
|
||||
<programlisting>
|
||||
with <replaceable>e1</replaceable>; <replaceable>e2</replaceable></programlisting>
|
||||
|
||||
introduces the set <replaceable>e1</replaceable> into the lexical
|
||||
scope of the expression <replaceable>e2</replaceable>. For instance,
|
||||
|
||||
<programlisting>
|
||||
let as = { x = "foo"; y = "bar"; };
|
||||
in with as; x + y</programlisting>
|
||||
|
||||
evaluates to <literal>"foobar"</literal> since the
|
||||
<literal>with</literal> adds the <varname>x</varname> and
|
||||
<varname>y</varname> attributes of <varname>as</varname> to the
|
||||
lexical scope in the expression <literal>x + y</literal>. The most
|
||||
common use of <literal>with</literal> is in conjunction with the
|
||||
<function>import</function> function. E.g.,
|
||||
|
||||
<programlisting>
|
||||
with (import ./definitions.nix); ...</programlisting>
|
||||
|
||||
makes all attributes defined in the file
|
||||
<filename>definitions.nix</filename> available as if they were defined
|
||||
locally in a <literal>rec</literal>-expression.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Comments</title>
|
||||
|
||||
<para>Comments can be single-line, started with a <literal>#</literal>
|
||||
character, or inline/multi-line, enclosed within <literal>/*
|
||||
... */</literal>.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
</section>
|
||||
@@ -0,0 +1,113 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-language-operators">
|
||||
|
||||
<title>Operators</title>
|
||||
|
||||
<para><xref linkend='table-operators' /> lists the operators in the
|
||||
Nix expression language, in order of precedence (from strongest to
|
||||
weakest binding).</para>
|
||||
|
||||
<table xml:id='table-operators'>
|
||||
<title>Operators</title>
|
||||
<tgroup cols='3'>
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Syntax</entry>
|
||||
<entry>Associativity</entry>
|
||||
<entry>Description</entry>
|
||||
</row>
|
||||
</thead>
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><replaceable>e</replaceable> <literal>.</literal>
|
||||
<replaceable>attrpath</replaceable>
|
||||
[ <literal>or</literal> <replaceable>def</replaceable> ]
|
||||
</entry>
|
||||
<entry>none</entry>
|
||||
<entry>Select attribute denoted by the attribute path
|
||||
<replaceable>attrpath</replaceable> from set
|
||||
<replaceable>e</replaceable>. (An attribute path is a
|
||||
dot-separated list of attribute names.) If the attribute
|
||||
doesn’t exist, return <replaceable>def</replaceable> if
|
||||
provided, otherwise abort evaluation.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><replaceable>e1</replaceable> <replaceable>e2</replaceable></entry>
|
||||
<entry>left</entry>
|
||||
<entry>Call function <replaceable>e1</replaceable> with
|
||||
argument <replaceable>e2</replaceable>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><replaceable>e</replaceable> <literal>?</literal>
|
||||
<replaceable>attrpath</replaceable></entry>
|
||||
<entry>none</entry>
|
||||
<entry>Test whether set <replaceable>e</replaceable> contains
|
||||
the attribute denoted by <replaceable>attrpath</replaceable>;
|
||||
return <literal>true</literal> or
|
||||
<literal>false</literal>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><replaceable>e1</replaceable> <literal>++</literal> <replaceable>e2</replaceable></entry>
|
||||
<entry>right</entry>
|
||||
<entry>List concatenation.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><replaceable>e1</replaceable> <literal>+</literal> <replaceable>e2</replaceable></entry>
|
||||
<entry>left</entry>
|
||||
<entry>String or path concatenation.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>!</literal> <replaceable>e</replaceable></entry>
|
||||
<entry>left</entry>
|
||||
<entry>Boolean negation.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><replaceable>e1</replaceable> <literal>//</literal>
|
||||
<replaceable>e2</replaceable></entry>
|
||||
<entry>right</entry>
|
||||
<entry>Return a set consisting of the attributes in
|
||||
<replaceable>e1</replaceable> and
|
||||
<replaceable>e2</replaceable> (with the latter taking
|
||||
precedence over the former in case of equally named
|
||||
attributes).</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><replaceable>e1</replaceable> <literal>==</literal>
|
||||
<replaceable>e2</replaceable></entry>
|
||||
<entry>none</entry>
|
||||
<entry>Equality.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><replaceable>e1</replaceable> <literal>!=</literal>
|
||||
<replaceable>e2</replaceable></entry>
|
||||
<entry>none</entry>
|
||||
<entry>Inequality.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><replaceable>e1</replaceable> <literal>&&</literal>
|
||||
<replaceable>e2</replaceable></entry>
|
||||
<entry>left</entry>
|
||||
<entry>Logical AND.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><replaceable>e1</replaceable> <literal>||</literal>
|
||||
<replaceable>e2</replaceable></entry>
|
||||
<entry>left</entry>
|
||||
<entry>Logical OR.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><replaceable>e1</replaceable> <literal>-></literal>
|
||||
<replaceable>e2</replaceable></entry>
|
||||
<entry>none</entry>
|
||||
<entry>Logical implication (equivalent to
|
||||
<literal>!<replaceable>e1</replaceable> ||
|
||||
<replaceable>e2</replaceable></literal>).</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
</section>
|
||||
@@ -0,0 +1,271 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='ssec-values'>
|
||||
|
||||
<title>Values</title>
|
||||
|
||||
|
||||
<simplesect><title>Simple Values</title>
|
||||
|
||||
<para>Nix has the following basic data types:
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem>
|
||||
|
||||
<para><emphasis>Strings</emphasis> can be written in three
|
||||
ways.</para>
|
||||
|
||||
<para>The most common way is to enclose the string between double
|
||||
quotes, e.g., <literal>"foo bar"</literal>. Strings can span
|
||||
multiple lines. The special characters <literal>"</literal> and
|
||||
<literal>\</literal> and the character sequence
|
||||
<literal>${</literal> must be escaped by prefixing them with a
|
||||
backslash (<literal>\</literal>). Newlines, carriage returns and
|
||||
tabs can be written as <literal>\n</literal>,
|
||||
<literal>\r</literal> and <literal>\t</literal>,
|
||||
respectively.</para>
|
||||
|
||||
<para>You can include the result of an expression into a string by
|
||||
enclosing it in
|
||||
<literal>${<replaceable>...</replaceable>}</literal>, a feature
|
||||
known as <emphasis>antiquotation</emphasis>. The enclosed
|
||||
expression must evaluate to something that can be coerced into a
|
||||
string (meaning that it must be a string, a path, or a
|
||||
derivation). For instance, rather than writing
|
||||
|
||||
<programlisting>
|
||||
"--with-freetype2-library=" + freetype + "/lib"</programlisting>
|
||||
|
||||
(where <varname>freetype</varname> is a derivation), you can
|
||||
instead write the more natural
|
||||
|
||||
<programlisting>
|
||||
"--with-freetype2-library=${freetype}/lib"</programlisting>
|
||||
|
||||
The latter is automatically translated to the former. A more
|
||||
complicated example (from the Nix expression for <link
|
||||
xlink:href='http://www.trolltech.com/products/qt'>Qt</link>):
|
||||
|
||||
<programlisting>
|
||||
configureFlags = "
|
||||
-system-zlib -system-libpng -system-libjpeg
|
||||
${if openglSupport then "-dlopen-opengl
|
||||
-L${mesa}/lib -I${mesa}/include
|
||||
-L${libXmu}/lib -I${libXmu}/include" else ""}
|
||||
${if threadSupport then "-thread" else "-no-thread"}
|
||||
";</programlisting>
|
||||
|
||||
Note that Nix expressions and strings can be arbitrarily nested;
|
||||
in this case the outer string contains various antiquotations that
|
||||
themselves contain strings (e.g., <literal>"-thread"</literal>),
|
||||
some of which in turn contain expressions (e.g.,
|
||||
<literal>${mesa}</literal>).</para>
|
||||
|
||||
<para>The second way to write string literals is as an
|
||||
<emphasis>indented string</emphasis>, which is enclosed between
|
||||
pairs of <emphasis>double single-quotes</emphasis>, like so:
|
||||
|
||||
<programlisting>
|
||||
''
|
||||
This is the first line.
|
||||
This is the second line.
|
||||
This is the third line.
|
||||
''</programlisting>
|
||||
|
||||
This kind of string literal intelligently strips indentation from
|
||||
the start of each line. To be precise, it strips from each line a
|
||||
number of spaces equal to the minimal indentation of the string as
|
||||
a whole (disregarding the indentation of empty lines). For
|
||||
instance, the first and second line are indented two space, while
|
||||
the third line is indented four spaces. Thus, two spaces are
|
||||
stripped from each line, so the resulting string is
|
||||
|
||||
<programlisting>
|
||||
"This is the first line.\nThis is the second line.\n This is the third line.\n"</programlisting>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Note that the whitespace and newline following the opening
|
||||
<literal>''</literal> is ignored if there is no non-whitespace
|
||||
text on the initial line.</para>
|
||||
|
||||
<para>Antiquotation
|
||||
(<literal>${<replaceable>expr</replaceable>}</literal>) is
|
||||
supported in indented strings.</para>
|
||||
|
||||
<para>Since <literal>${</literal> and <literal>''</literal> have
|
||||
special meaning in indented strings, you need a way to quote them.
|
||||
<literal>${</literal> can be escaped by prefixing it with
|
||||
<literal>''</literal> (that is, two single quotes), i.e.,
|
||||
<literal>''${</literal>. <literal>''</literal> can be escaped by
|
||||
prefixing it with <literal>'</literal>, i.e.,
|
||||
<literal>'''</literal>. Finally, linefeed, carriage-return and
|
||||
tab characters can be written as <literal>''\n</literal>,
|
||||
<literal>''\r</literal>, <literal>''\t</literal>.</para>
|
||||
|
||||
<para>Indented strings are primarily useful in that they allow
|
||||
multi-line string literals to follow the indentation of the
|
||||
enclosing Nix expression, and that less escaping is typically
|
||||
necessary for strings representing languages such as shell scripts
|
||||
and configuration files because <literal>''</literal> is much less
|
||||
common than <literal>"</literal>. Example:
|
||||
|
||||
<programlisting>
|
||||
stdenv.mkDerivation {
|
||||
<replaceable>...</replaceable>
|
||||
postInstall =
|
||||
''
|
||||
mkdir $out/bin $out/etc
|
||||
cp foo $out/bin
|
||||
echo "Hello World" > $out/etc/foo.conf
|
||||
${if enableBar then "cp bar $out/bin" else ""}
|
||||
'';
|
||||
<replaceable>...</replaceable>
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Finally, as a convenience, <emphasis>URIs</emphasis> as
|
||||
defined in appendix B of <link
|
||||
xlink:href='http://www.ietf.org/rfc/rfc2396.txt'>RFC 2396</link>
|
||||
can be written <emphasis>as is</emphasis>, without quotes. For
|
||||
instance, the string
|
||||
<literal>"http://example.org/foo.tar.bz2"</literal>
|
||||
can also be written as
|
||||
<literal>http://example.org/foo.tar.bz2</literal>.</para>
|
||||
|
||||
</listitem>
|
||||
|
||||
<listitem><para><emphasis>Integers</emphasis>, e.g.,
|
||||
<literal>123</literal>.</para></listitem>
|
||||
|
||||
<listitem><para><emphasis>Paths</emphasis>, e.g.,
|
||||
<filename>/bin/sh</filename> or <filename>./builder.sh</filename>.
|
||||
A path must contain at least one slash to be recognised as such; for
|
||||
instance, <filename>builder.sh</filename> is not a
|
||||
path<footnote><para>It's parsed as an expression that selects the
|
||||
attribute <varname>sh</varname> from the variable
|
||||
<varname>builder</varname>.</para></footnote>. If the file name is
|
||||
relative, i.e., if it does not begin with a slash, it is made
|
||||
absolute at parse time relative to the directory of the Nix
|
||||
expression that contained it. For instance, if a Nix expression in
|
||||
<filename>/foo/bar/bla.nix</filename> refers to
|
||||
<filename>../xyzzy/fnord.nix</filename>, the absolute path is
|
||||
<filename>/foo/xyzzy/fnord.nix</filename>.</para></listitem>
|
||||
|
||||
<listitem><para><emphasis>Booleans</emphasis> with values
|
||||
<literal>true</literal> and
|
||||
<literal>false</literal>.</para></listitem>
|
||||
|
||||
<listitem><para>The null value, denoted as
|
||||
<literal>null</literal>.</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Lists</title>
|
||||
|
||||
<para>Lists are formed by enclosing a whitespace-separated list of
|
||||
values between square brackets. For example,
|
||||
|
||||
<programlisting>
|
||||
[ 123 ./foo.nix "abc" (f { x = y; }) ]</programlisting>
|
||||
|
||||
defines a list of four elements, the last being the result of a call
|
||||
to the function <varname>f</varname>. Note that function calls have
|
||||
to be enclosed in parentheses. If they had been omitted, e.g.,
|
||||
|
||||
<programlisting>
|
||||
[ 123 ./foo.nix "abc" f { x = y; } ]</programlisting>
|
||||
|
||||
the result would be a list of five elements, the fourth one being a
|
||||
function and the fifth being a set.</para>
|
||||
|
||||
<para>Note that lists are only lazy in values, and they are strict in length.
|
||||
</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Sets</title>
|
||||
|
||||
<para>Sets are really the core of the language, since ultimately the
|
||||
Nix language is all about creating derivations, which are really just
|
||||
sets of attributes to be passed to build scripts.</para>
|
||||
|
||||
<para>Sets are just a list of name/value pairs (called
|
||||
<emphasis>attributes</emphasis>) enclosed in curly brackets, where
|
||||
each value is an arbitrary expression terminated by a semicolon. For
|
||||
example:
|
||||
|
||||
<programlisting>
|
||||
{ x = 123;
|
||||
text = "Hello";
|
||||
y = f { bla = 456; };
|
||||
}</programlisting>
|
||||
|
||||
This defines a set with attributes named <varname>x</varname>,
|
||||
<varname>text</varname>, <varname>y</varname>. The order of the
|
||||
attributes is irrelevant. An attribute name may only occur
|
||||
once.</para>
|
||||
|
||||
<para>Attributes can be selected from a set using the
|
||||
<literal>.</literal> operator. For instance,
|
||||
|
||||
<programlisting>
|
||||
{ a = "Foo"; b = "Bar"; }.a</programlisting>
|
||||
|
||||
evaluates to <literal>"Foo"</literal>. It is possible to provide a
|
||||
default value in an attribute selection using the
|
||||
<literal>or</literal> keyword. For example,
|
||||
|
||||
<programlisting>
|
||||
{ a = "Foo"; b = "Bar"; }.c or "Xyzzy"</programlisting>
|
||||
|
||||
will evaluate to <literal>"Xyzzy"</literal> because there is no
|
||||
<varname>c</varname> attribute in the set.</para>
|
||||
|
||||
<para>You can use arbitrary double-quoted strings as attribute
|
||||
names:
|
||||
|
||||
<programlisting>
|
||||
{ "foo ${bar}" = 123; "nix-1.0" = 456; }."foo ${bar}"
|
||||
</programlisting>
|
||||
|
||||
This will evaluate to <literal>123</literal> (Assuming
|
||||
<literal>bar</literal> is antiquotable). In the case where an
|
||||
attribute name is just a single antiquotation, the quotes can be
|
||||
dropped:
|
||||
|
||||
<programlisting>
|
||||
{ foo = 123; }.${bar} or 456 </programlisting>
|
||||
|
||||
This will evaluate to <literal>123</literal> if
|
||||
<literal>bar</literal> evaluates to <literal>"foo"</literal> when
|
||||
coerced to a string and <literal>456</literal> otherwise (again
|
||||
assuming <literal>bar</literal> is antiquotable).</para>
|
||||
|
||||
<para>In the special case where an attribute name inside of a set declaration
|
||||
evaluates to <literal>null</literal> (which is normally an error, as
|
||||
<literal>null</literal> is not antiquotable), that attribute is simply not
|
||||
added to the set:
|
||||
|
||||
<programlisting>
|
||||
{ ${if foo then "bar" else null} = true; }</programlisting>
|
||||
|
||||
This will evaluate to <literal>{}</literal> if <literal>foo</literal>
|
||||
evaluates to <literal>false</literal>.</para>
|
||||
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
</section>
|
||||
@@ -0,0 +1,88 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='sec-building-simple'>
|
||||
|
||||
<title>Building and Testing</title>
|
||||
|
||||
<para>You can now try to build Hello. Of course, you could do
|
||||
<literal>nix-env -f pkgs/top-level/all-packages.nix -i hello</literal>,
|
||||
but you may not want to install a possibly broken package just yet.
|
||||
The best way to test the package is by using the command <command
|
||||
linkend="sec-nix-build">nix-build</command>, which builds a Nix
|
||||
expression and creates a symlink named <filename>result</filename> in
|
||||
the current directory:
|
||||
|
||||
<screen>
|
||||
$ nix-build pkgs/top-level/all-packages.nix -A hello
|
||||
building path `/nix/store/632d2b22514d...-hello-2.1.1'
|
||||
hello-2.1.1/
|
||||
hello-2.1.1/intl/
|
||||
hello-2.1.1/intl/ChangeLog
|
||||
<replaceable>...</replaceable>
|
||||
|
||||
$ ls -l result
|
||||
lrwxrwxrwx ... 2006-09-29 10:43 result -> /nix/store/632d2b22514d...-hello-2.1.1
|
||||
|
||||
$ ./result/bin/hello
|
||||
Hello, world!</screen>
|
||||
|
||||
The <link linkend='opt-attr'><option>-A</option></link> option selects
|
||||
the <literal>hello</literal> attribute from
|
||||
<filename>all-packages.nix</filename>. This is faster than using the
|
||||
symbolic package name specified by the <literal>name</literal>
|
||||
attribute (which also happens to be <literal>hello</literal>) and is
|
||||
unambiguous (there can be multiple packages with the symbolic name
|
||||
<literal>hello</literal>, but there can be only one attribute in a set
|
||||
named <literal>hello</literal>).</para>
|
||||
|
||||
<para><command>nix-build</command> registers the
|
||||
<filename>./result</filename> symlink as a garbage collection root, so
|
||||
unless and until you delete the <filename>./result</filename> symlink,
|
||||
the output of the build will be safely kept on your system. You can
|
||||
use <command>nix-build</command>’s <option
|
||||
linkend='opt-out-link'>-o</option> switch to give the symlink another
|
||||
name.</para>
|
||||
|
||||
<para>Nix has a transactional semantics. Once a build finishes
|
||||
successfully, Nix makes a note of this in its database: it registers
|
||||
that the path denoted by <envar>out</envar> is now
|
||||
<quote>valid</quote>. If you try to build the derivation again, Nix
|
||||
will see that the path is already valid and finish immediately. If a
|
||||
build fails, either because it returns a non-zero exit code, because
|
||||
Nix or the builder are killed, or because the machine crashes, then
|
||||
the output paths will not be registered as valid. If you try to build
|
||||
the derivation again, Nix will remove the output paths if they exist
|
||||
(e.g., because the builder died half-way through <literal>make
|
||||
install</literal>) and try again. Note that there is no
|
||||
<quote>negative caching</quote>: Nix doesn't remember that a build
|
||||
failed, and so a failed build can always be repeated. This is because
|
||||
Nix cannot distinguish between permanent failures (e.g., a compiler
|
||||
error due to a syntax error in the source) and transient failures
|
||||
(e.g., a disk full condition).</para>
|
||||
|
||||
<para>Nix also performs locking. If you run multiple Nix builds
|
||||
simultaneously, and they try to build the same derivation, the first
|
||||
Nix instance that gets there will perform the build, while the others
|
||||
block (or perform other derivations if available) until the build
|
||||
finishes:
|
||||
|
||||
<screen>
|
||||
$ nix-build pkgs/top-level/all-packages.nix -A hello
|
||||
waiting for lock on `/nix/store/0h5b7hp8d4hqfrw8igvx97x1xawrjnac-hello-2.1.1x'</screen>
|
||||
|
||||
So it is always safe to run multiple instances of Nix in parallel
|
||||
(which isn’t the case with, say, <command>make</command>).</para>
|
||||
|
||||
<para>If you have a system with multiple CPUs, you may want to have
|
||||
Nix build different derivations in parallel (insofar as possible).
|
||||
Just pass the option <link linkend='opt-max-jobs'><option>-j
|
||||
<replaceable>N</replaceable></option></link>, where
|
||||
<replaceable>N</replaceable> is the maximum number of jobs to be run
|
||||
in parallel, or set. Typically this should be the number of
|
||||
CPUs.</para>
|
||||
|
||||
<xi:include href="debug-build.xml" />
|
||||
|
||||
</section>
|
||||
@@ -0,0 +1,47 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-simple-expression">
|
||||
|
||||
<title>A Simple Nix Expression</title>
|
||||
|
||||
<para>This section shows how to add and test the <link
|
||||
xlink:href='http://www.gnu.org/software/hello/hello.html'>GNU Hello
|
||||
package</link> to the Nix Packages collection. Hello is a program
|
||||
that prints out the text <quote>Hello, world!</quote>.</para>
|
||||
|
||||
<para>To add a package to the Nix Packages collection, you generally
|
||||
need to do three things:
|
||||
|
||||
<orderedlist>
|
||||
|
||||
<listitem><para>Write a Nix expression for the package. This is a
|
||||
file that describes all the inputs involved in building the package,
|
||||
such as dependencies, sources, and so on.</para></listitem>
|
||||
|
||||
<listitem><para>Write a <emphasis>builder</emphasis>. This is a
|
||||
shell script<footnote><para>In fact, it can be written in any
|
||||
language, but typically it's a <command>bash</command> shell
|
||||
script.</para></footnote> that actually builds the package from
|
||||
the inputs.</para></listitem>
|
||||
|
||||
<listitem><para>Add the package to the file
|
||||
<filename>pkgs/top-level/all-packages.nix</filename>. The Nix
|
||||
expression written in the first step is a
|
||||
<emphasis>function</emphasis>; it requires other packages in order
|
||||
to build it. In this step you put it all together, i.e., you call
|
||||
the function with the right arguments to build the actual
|
||||
package.</para></listitem>
|
||||
|
||||
</orderedlist>
|
||||
|
||||
</para>
|
||||
|
||||
<xi:include href="expression-syntax.xml" />
|
||||
<xi:include href="build-script.xml" />
|
||||
<xi:include href="arguments-variables.xml" />
|
||||
<xi:include href="simple-building-testing.xml" />
|
||||
<xi:include href="generic-builder.xml" />
|
||||
|
||||
</chapter>
|
||||
@@ -0,0 +1,26 @@
|
||||
<part xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id='chap-writing-nix-expressions'>
|
||||
|
||||
<title>Writing Nix Expressions</title>
|
||||
|
||||
<partintro>
|
||||
<para>This chapter shows you how to write Nix expressions, which
|
||||
instruct Nix how to build packages. It starts with a
|
||||
simple example (a Nix expression for GNU Hello), and then moves
|
||||
on to a more in-depth look at the Nix expression language.</para>
|
||||
|
||||
<note><para>This chapter is mostly about the Nix expression language.
|
||||
For more extensive information on adding packages to the Nix Packages
|
||||
collection (such as functions in the standard environment and coding
|
||||
conventions), please consult <link
|
||||
xlink:href="http://nixos.org/nixpkgs/manual/">its
|
||||
manual</link>.</para></note>
|
||||
</partintro>
|
||||
|
||||
<xi:include href="simple-expression.xml" />
|
||||
<xi:include href="expression-language.xml" />
|
||||
|
||||
</part>
|
||||
|
Before Width: | Height: | Size: 83 KiB After Width: | Height: | Size: 83 KiB |
@@ -0,0 +1,41 @@
|
||||
<appendix xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="chap-hacking">
|
||||
|
||||
<title>Hacking</title>
|
||||
|
||||
<para>This section provides some notes on how to hack on Nix. To get
|
||||
the latest version of Nix from GitHub:
|
||||
<screen>
|
||||
$ git clone git://github.com/NixOS/nix.git
|
||||
$ cd nix
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>To build it and its dependencies:
|
||||
<screen>
|
||||
$ nix-build release.nix -A build.x86_64-linux
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>To build all dependencies and start a shell in which all
|
||||
environment variables are set up so that those dependencies can be
|
||||
found:
|
||||
<screen>
|
||||
$ ./dev-shell
|
||||
</screen>
|
||||
To build Nix itself in this shell:
|
||||
<screen>
|
||||
[nix-shell]$ ./bootstrap.sh
|
||||
[nix-shell]$ configurePhase
|
||||
[nix-shell]$ make
|
||||
</screen>
|
||||
To test it:
|
||||
<screen>
|
||||
[nix-shell]$ make install
|
||||
[nix-shell]$ make installcheck
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
</appendix>
|
||||
|
After Width: | Height: | Size: 889 B |
|
After Width: | Height: | Size: 929 B |
|
After Width: | Height: | Size: 202 B |
|
After Width: | Height: | Size: 210 B |
|
After Width: | Height: | Size: 209 B |
|
After Width: | Height: | Size: 205 B |
|
After Width: | Height: | Size: 210 B |
|
After Width: | Height: | Size: 907 B |
|
After Width: | Height: | Size: 914 B |
|
After Width: | Height: | Size: 907 B |
|
After Width: | Height: | Size: 916 B |
|
After Width: | Height: | Size: 218 B |
|
After Width: | Height: | Size: 907 B |
|
After Width: | Height: | Size: 918 B |
|
After Width: | Height: | Size: 923 B |
@@ -1,550 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="chap-installation">
|
||||
|
||||
<title>Installation</title>
|
||||
|
||||
|
||||
<section><title>Supported platforms</title>
|
||||
|
||||
<para>Nix is currently supported on the following platforms:
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para>Linux (particularly on x86, x86_64, and
|
||||
PowerPC).</para></listitem>
|
||||
|
||||
<listitem><para>Mac OS X.</para></listitem>
|
||||
|
||||
<listitem><para>FreeBSD (only tested on Intel).</para></listitem>
|
||||
|
||||
<!--
|
||||
<listitem><para>Windows through <link
|
||||
xlink:href="http://www.cygwin.com/">Cygwin</link>.</para>
|
||||
|
||||
<warning><para>On Cygwin, Nix <emphasis>must</emphasis> be installed
|
||||
on an NTFS partition. It will not work correctly on a FAT
|
||||
partition.</para></warning>
|
||||
|
||||
</listitem>
|
||||
-->
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Nix is pretty portable, so it should work on most other Unix
|
||||
platforms as well.</para>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<section><title>Installing a binary distribution</title>
|
||||
|
||||
<para>The easiest way to install Nix is to use a binary package.
|
||||
Binary packages of the latest stable release are available for Fedora,
|
||||
Debian, Ubuntu, Mac OS X and various other systems from the <link
|
||||
xlink:href="http://nixos.org/nix/download.html">Nix homepage</link>.
|
||||
You can also get builds of the latest development release from our
|
||||
<link
|
||||
xlink:href="http://hydra.nixos.org/view/nix/trunk/latest">continuous
|
||||
build system</link>.</para>
|
||||
|
||||
<para>For Fedora, RPM packages are available. These can be installed
|
||||
or upgraded using <command>rpm -U</command>. For example,
|
||||
|
||||
<screen>
|
||||
$ rpm -U nix-1.0-1.i386.rpm</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>For Debian and Ubuntu, you can download a Deb package and
|
||||
install it like this:
|
||||
|
||||
<screen>
|
||||
$ dpkg -i nix_1.0-1_amd64.deb</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>For other platforms, including Mac OS X (Darwin), FreeBSD and
|
||||
other Linux distributions, you can download a binary tarball. It
|
||||
contains Nix and all its dependencies. You should unpack it in the
|
||||
root directory, then run <command>nix-finish-install</command>:
|
||||
|
||||
<screen>
|
||||
$ cd /
|
||||
$ tar xfj nix-1.1-x86_64-darwin.tar.bz2
|
||||
$ nix-finish-install
|
||||
</screen>
|
||||
|
||||
After this you can delete
|
||||
<filename>/usr/bin/nix-finish-install</filename>.</para>
|
||||
|
||||
<para>If you plan to use Nix from a single non-root user account, it’s
|
||||
probably convenient to change the ownership of the entire Nix store
|
||||
and database to that user account. In that case, install as follows:
|
||||
|
||||
<screen>
|
||||
alice$ cd /
|
||||
alice$ sudo tar xfj nix-1.1-x86_64-darwin.tar.bz2
|
||||
alice$ sudo chown -R alice /nix
|
||||
alice$ nix-finish-install
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Nix can be uninstalled using <command>rpm -e nix</command> or
|
||||
<command>dpkg -r nix</command> on RPM- and Dpkg-based systems,
|
||||
respectively. After this you should manually remove the Nix store and
|
||||
other auxiliary data, if desired:
|
||||
|
||||
<screen>
|
||||
$ rm -rf /nix</screen>
|
||||
|
||||
</para>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<section><title>Installing Nix from source</title>
|
||||
|
||||
<para>If no binary package is available, you can download and compile
|
||||
a source distribution.</para>
|
||||
|
||||
<section><title>Prerequisites</title>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para>GNU Make.</para></listitem>
|
||||
|
||||
<listitem><para>A fairly recent version of GCC/G++. Version 2.95
|
||||
and higher should work. Clang will also work.</para></listitem>
|
||||
|
||||
<listitem><para>Perl 5.8 or higher.</para></listitem>
|
||||
|
||||
<listitem><para><command>pkg-config</command> to locate
|
||||
dependencies. If your distribution does not provide it, you can get
|
||||
it from <link
|
||||
xlink:href="http://www.freedesktop.org/wiki/Software/pkg-config"
|
||||
/>.</para></listitem>
|
||||
|
||||
<listitem><para>The bzip2 compressor program and the
|
||||
<literal>libbz2</literal> library. Thus you must have bzip2
|
||||
installed, including development headers and libraries. If your
|
||||
distribution does not provide these, you can obtain bzip2 from <link
|
||||
xlink:href="http://www.bzip.org/"/>.</para></listitem>
|
||||
|
||||
<listitem><para>The SQLite embedded database library, version 3.6.19
|
||||
or higher. If your distribution does not provide it, please install
|
||||
it from <link xlink:href="http://www.sqlite.org/" />.</para></listitem>
|
||||
|
||||
<listitem><para>The Perl DBI and DBD::SQLite libraries, which are
|
||||
available from <link
|
||||
xlink:href="http://search.cpan.org/">CPAN</link> if your
|
||||
distribution does not provide them.</para></listitem>
|
||||
|
||||
<listitem><para>The <link
|
||||
xlink:href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/">Boehm
|
||||
garbage collector</link> to reduce the evaluator’s memory
|
||||
consumption (optional). To enable it, install
|
||||
<literal>pkgconfig</literal> and the Boehm garbage collector, and
|
||||
pass the flag <option>--enable-gc</option> to
|
||||
<command>configure</command>.</para></listitem>
|
||||
|
||||
<listitem><para>The <command>xmllint</command> and
|
||||
<command>xsltproc</command> programs to build this manual and the
|
||||
man-pages. These are part of the <literal>libxml2</literal> and
|
||||
<literal>libxslt</literal> packages, respectively. You also need
|
||||
the <link
|
||||
xlink:href="http://docbook.sourceforge.net/projects/xsl/">DocBook
|
||||
XSL stylesheets</link> and optionally the <link
|
||||
xlink:href="http://www.docbook.org/schemas/5x"> DocBook 5.0 RELAX NG
|
||||
schemas</link>. Note that these are only required if you modify the
|
||||
manual sources or when you are building from the Git
|
||||
repository.</para></listitem>
|
||||
|
||||
<listitem><para>Recent versions of Bison and Flex to build the
|
||||
parser. (This is because Nix needs GLR support in Bison and
|
||||
reentrancy support in Flex.) For Bison, you need version 2.3 or
|
||||
higher (1.875 does <emphasis>not</emphasis> work), which can be
|
||||
obtained from the <link
|
||||
xlink:href="ftp://alpha.gnu.org/pub/gnu/bison">GNU FTP
|
||||
server</link>. For Flex, you need version 2.5.33, which is
|
||||
available on <link
|
||||
xlink:href="http://lex.sourceforge.net/">SourceForge</link>.
|
||||
Slightly older versions may also work, but ancient versions like the
|
||||
ubiquitous 2.5.4a won't. Note that these are only required if you
|
||||
modify the parser or when you are building from the Git
|
||||
repository.</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<section><title>Obtaining a source distribution</title>
|
||||
|
||||
<para>The source tarball of the most recent stable release can be
|
||||
downloaded from the <link
|
||||
xlink:href="http://nixos.org/nix/download.html">Nix homepage</link>.
|
||||
You can also grab the <link
|
||||
xlink:href="http://hydra.nixos.org/view/nix/trunk/latest/tarball/download-by-type/file/source-dist">most
|
||||
recent development release</link>.</para>
|
||||
|
||||
<para>Alternatively, the most recent sources of Nix can be obtained
|
||||
from its <link
|
||||
xlink:href="https://github.com/NixOS/nix">Git
|
||||
repository</link>. For example, the following command will check out
|
||||
the latest revision into a directory called
|
||||
<filename>nix</filename>:</para>
|
||||
|
||||
<screen>
|
||||
$ git clone https://github.com/NixOS/nix</screen>
|
||||
|
||||
<para>Likewise, specific releases can be obtained from the <link
|
||||
xlink:href="https://github.com/NixOS/nix/tags">tags</link> of the
|
||||
repository.</para>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<section><title>Building Nix from source</title>
|
||||
|
||||
<para>After unpacking or checking out the Nix sources, issue the
|
||||
following commands:
|
||||
|
||||
<screen>
|
||||
$ ./configure <replaceable>options...</replaceable>
|
||||
$ make
|
||||
$ make install</screen>
|
||||
|
||||
Nix requires GNU Make so you may need to invoke
|
||||
<command>gmake</command> instead.</para>
|
||||
|
||||
<para>When building from the Git repository, these should be preceded
|
||||
by the command:
|
||||
|
||||
<screen>
|
||||
$ ./bootstrap.sh</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>The installation path can be specified by passing the
|
||||
<option>--prefix=<replaceable>prefix</replaceable></option> to
|
||||
<command>configure</command>. The default installation directory is
|
||||
<filename>/usr/local</filename>. You can change this to any location
|
||||
you like. You must have write permission to the
|
||||
<replaceable>prefix</replaceable> path.</para>
|
||||
|
||||
<para>Nix keeps its <emphasis>store</emphasis> (the place where
|
||||
packages are stored) in <filename>/nix/store</filename> by default.
|
||||
This can be changed using
|
||||
<option>--with-store-dir=<replaceable>path</replaceable></option>.</para>
|
||||
|
||||
<warning><para>It is best <emphasis>not</emphasis> to change the Nix
|
||||
store from its default, since doing so makes it impossible to use
|
||||
pre-built binaries from the standard Nixpkgs channels — that is, all
|
||||
packages will need to be built from source.</para></warning>
|
||||
|
||||
<para>Nix keeps state (such as its database and log files) in
|
||||
<filename>/nix/var</filename> by default. This can be changed using
|
||||
<option>--localstatedir=<replaceable>path</replaceable></option>.</para>
|
||||
|
||||
<para>If you want to rebuild the documentation, pass the full path to
|
||||
the DocBook RELAX NG schemas and to the DocBook XSL stylesheets using
|
||||
the
|
||||
<option>--with-docbook-rng=<replaceable>path</replaceable></option>
|
||||
and
|
||||
<option>--with-docbook-xsl=<replaceable>path</replaceable></option>
|
||||
options.</para>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<!-- TODO: should be updated
|
||||
<section><title>Upgrading Nix through Nix</title>
|
||||
|
||||
<para>You can install the latest stable version of Nix through Nix
|
||||
itself by subscribing to the channel <link
|
||||
xlink:href="http://nixos.org/releases/nix/channels/nix-stable" />,
|
||||
or the latest unstable version by subscribing to the channel <link
|
||||
xlink:href="http://nixos.org/releases/nix/channels/nix-unstable" />.
|
||||
You can also do a <link linkend="sec-one-click">one-click
|
||||
installation</link> by clicking on the package links at <link
|
||||
xlink:href="http://nixos.org/releases/full-index-nix.html" />.</para>
|
||||
|
||||
</section>
|
||||
-->
|
||||
|
||||
|
||||
<section><title>Security</title>
|
||||
|
||||
<para>Nix has two basic security models. First, it can be used in
|
||||
“single-user mode”, which is similar to what most other package
|
||||
management tools do: there is a single user (typically <systemitem
|
||||
class="username">root</systemitem>) who performs all package
|
||||
management operations. All other users can then use the installed
|
||||
packages, but they cannot perform package management operations
|
||||
themselves.</para>
|
||||
|
||||
<para>Alternatively, you can configure Nix in “multi-user mode”. In
|
||||
this model, all users can perform package management operations — for
|
||||
instance, every user can install software without requiring root
|
||||
privileges. Nix ensures that this is secure. For instance, it’s not
|
||||
possible for one user to overwrite a package used by another user with
|
||||
a Trojan horse.</para>
|
||||
|
||||
|
||||
<section><title>Single-user mode</title>
|
||||
|
||||
<para>In single-user mode, all Nix operations that access the database
|
||||
in <filename><replaceable>prefix</replaceable>/var/nix/db</filename>
|
||||
or modify the Nix store in
|
||||
<filename><replaceable>prefix</replaceable>/store</filename> must be
|
||||
performed under the user ID that owns those directories. This is
|
||||
typically <systemitem class="username">root</systemitem>. (If you
|
||||
install from RPM packages, that’s in fact the default ownership.)
|
||||
However, on single-user machines, it is often convenient to
|
||||
<command>chown</command> those directories to your normal user account
|
||||
so that you don’t have to <command>su</command> to <systemitem
|
||||
class="username">root</systemitem> all the time.</para>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<section xml:id="ssec-multi-user"><title>Multi-user mode</title>
|
||||
|
||||
<para>To allow a Nix store to be shared safely among multiple users,
|
||||
it is important that users are not able to run builders that modify
|
||||
the Nix store or database in arbitrary ways, or that interfere with
|
||||
builds started by other users. If they could do so, they could
|
||||
install a Trojan horse in some package and compromise the accounts of
|
||||
other users.</para>
|
||||
|
||||
<para>To prevent this, the Nix store and database are owned by some
|
||||
privileged user (usually <literal>root</literal>) and builders are
|
||||
executed under special user accounts (usually named
|
||||
<literal>nixbld1</literal>, <literal>nixbld2</literal>, etc.). When a
|
||||
unprivileged user runs a Nix command, actions that operate on the Nix
|
||||
store (such as builds) are forwarded to a <emphasis>Nix
|
||||
daemon</emphasis> running under the owner of the Nix store/database
|
||||
that performs the operation.</para>
|
||||
|
||||
<note><para>Multi-user mode has one important limitation: only
|
||||
<systemitem class="username">root</systemitem> can run <command
|
||||
linkend="sec-nix-pull">nix-pull</command> to register the availability
|
||||
of pre-built binaries. However, those registrations are shared by all
|
||||
users, so they still get the benefit from <command>nix-pull</command>s
|
||||
done by <systemitem class="username">root</systemitem>.</para></note>
|
||||
|
||||
|
||||
<section><title>Setting up the build users</title>
|
||||
|
||||
<para>The <emphasis>build users</emphasis> are the special UIDs under
|
||||
which builds are performed. They should all be members of the
|
||||
<emphasis>build users group</emphasis> (usually called
|
||||
<literal>nixbld</literal>). This group should have no other members.
|
||||
The build users should not be members of any other group.</para>
|
||||
|
||||
<para>Here is a typical <filename>/etc/group</filename> definition of
|
||||
the build users group with 10 build users:
|
||||
|
||||
<programlisting>
|
||||
nixbld:!:30000:nixbld1,nixbld2,nixbld3,nixbld4,nixbld5,nixbld6,nixbld7,nixbld8,nixbld9,nixbld10
|
||||
</programlisting>
|
||||
|
||||
In this example the <literal>nixbld</literal> group has UID 30000, but
|
||||
of course it can be anything that doesn’t collide with an existing
|
||||
group.</para>
|
||||
|
||||
<para>Here is the corresponding part of
|
||||
<filename>/etc/passwd</filename>:
|
||||
|
||||
<programlisting>
|
||||
nixbld1:x:30001:65534:Nix build user 1:/var/empty:/noshell
|
||||
nixbld2:x:30002:65534:Nix build user 2:/var/empty:/noshell
|
||||
nixbld3:x:30003:65534:Nix build user 3:/var/empty:/noshell
|
||||
...
|
||||
nixbld10:x:30010:65534:Nix build user 10:/var/empty:/noshell
|
||||
</programlisting>
|
||||
|
||||
The home directory of the build users should not exist or should be an
|
||||
empty directory to which they do not have write access.</para>
|
||||
|
||||
<para>The build users should have write access to the Nix store, but
|
||||
they should not have the right to delete files. Thus the Nix store’s
|
||||
group should be the build users group, and it should have the sticky
|
||||
bit turned on (like <filename>/tmp</filename>):
|
||||
|
||||
<screen>
|
||||
$ chgrp nixbld /nix/store
|
||||
$ chmod 1775 /nix/store
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Finally, you should tell Nix to use the build users by
|
||||
specifying the build users group in the <link
|
||||
linkend="conf-build-users-group"><literal>build-users-group</literal>
|
||||
option</link> in the <link linkend="sec-conf-file">Nix configuration
|
||||
file</link> (usually <literal>/etc/nix/nix.conf</literal>):
|
||||
|
||||
<programlisting>
|
||||
build-users-group = nixbld
|
||||
</programlisting>
|
||||
|
||||
</para>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<section><title>Nix store/database owned by root</title>
|
||||
|
||||
<para>The simplest setup is to let <literal>root</literal> own the Nix
|
||||
store and database. I.e.,
|
||||
|
||||
<screen>
|
||||
$ chown -R root /nix/store /nix/var/nix</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>The <link linkend="sec-nix-daemon">Nix daemon</link> should be
|
||||
started as follows (as <literal>root</literal>):
|
||||
|
||||
<screen>
|
||||
$ nix-daemon</screen>
|
||||
|
||||
You’ll want to put that line somewhere in your system’s boot
|
||||
scripts.</para>
|
||||
|
||||
<para>To let unprivileged users use the daemon, they should set the
|
||||
<link linkend="envar-remote"><envar>NIX_REMOTE</envar> environment
|
||||
variable</link> to <literal>daemon</literal>. So you should put a
|
||||
line like
|
||||
|
||||
<programlisting>
|
||||
export NIX_REMOTE=daemon</programlisting>
|
||||
|
||||
into the users’ login scripts.</para>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<section><title>Nix store/database not owned by root</title>
|
||||
|
||||
<para>It is also possible to let the Nix store and database be owned
|
||||
by a non-root user, which should be more secure<footnote><para>Note
|
||||
however that even when the Nix daemon runs as root, not
|
||||
<emphasis>that</emphasis> much code is executed as root: Nix
|
||||
expression evaluation is performed by the calling (unprivileged) user,
|
||||
and builds are performed under the special build user accounts. So
|
||||
only the code that accesses the database and starts builds is executed
|
||||
as <literal>root</literal>.</para></footnote>. Typically, this user
|
||||
is a special account called <literal>nix</literal>, but it can be
|
||||
named anything. It should own the Nix store and database:
|
||||
|
||||
<screen>
|
||||
$ chown -R nix /nix/store /nix/var/nix</screen>
|
||||
|
||||
and of course <command>nix-daemon</command> should be started under
|
||||
that user, e.g.,
|
||||
|
||||
<screen>
|
||||
$ su - nix -c "exec /nix/bin/nix-daemon"</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>There is a catch, though: non-<literal>root</literal> users
|
||||
cannot start builds under the build user accounts, since the
|
||||
<function>setuid</function> system call is obviously privileged. To
|
||||
allow a non-<literal>root</literal> Nix daemon to use the build user
|
||||
feature, it calls a setuid-root helper program,
|
||||
<command>nix-setuid-helper</command>. This program is installed in
|
||||
<filename><replaceable>prefix</replaceable>/libexec/nix-setuid-helper</filename>.
|
||||
To set the permissions properly (Nix’s <command>make install</command>
|
||||
doesn’t do this, since we don’t want to ship setuid-root programs
|
||||
out-of-the-box):
|
||||
|
||||
<screen>
|
||||
$ chown root.root /nix/libexec/nix-setuid-helper
|
||||
$ chmod 4755 /nix/libexec/nix-setuid-helper
|
||||
</screen>
|
||||
|
||||
(This example assumes that the Nix binaries are installed in
|
||||
<filename>/nix</filename>.)</para>
|
||||
|
||||
<para>Of course, the <command>nix-setuid-helper</command> command
|
||||
should not be usable by just anybody, since then anybody could run
|
||||
commands under the Nix build user accounts. For that reason there is
|
||||
a configuration file <filename>/etc/nix-setuid.conf</filename> that
|
||||
restricts the use of the helper. This file should be a text file
|
||||
containing precisely two lines, the first being the Nix daemon user
|
||||
and the second being the build users group, e.g.,
|
||||
|
||||
<programlisting>
|
||||
nix
|
||||
nixbld
|
||||
</programlisting>
|
||||
|
||||
The setuid-helper barfs if it is called by a user other than the one
|
||||
specified on the first line, or if it is asked to execute a build
|
||||
under a user who is not a member of the group specified on the second
|
||||
line. The file <filename>/etc/nix-setuid.conf</filename> must be
|
||||
owned by root, and must not be group- or world-writable. The
|
||||
setuid-helper barfs if this is not the case.</para>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<section><title>Restricting access</title>
|
||||
|
||||
<para>To limit which users can perform Nix operations, you can use the
|
||||
permissions on the directory
|
||||
<filename>/nix/var/nix/daemon-socket</filename>. For instance, if you
|
||||
want to restrict the use of Nix to the members of a group called
|
||||
<literal>nix-users</literal>, do
|
||||
|
||||
<screen>
|
||||
$ chgrp nix-users /nix/var/nix/daemon-socket
|
||||
$ chmod ug=rwx,o= /nix/var/nix/daemon-socket
|
||||
</screen>
|
||||
|
||||
This way, users who are not in the <literal>nix-users</literal> group
|
||||
cannot connect to the Unix domain socket
|
||||
<filename>/nix/var/nix/daemon-socket/socket</filename>, so they cannot
|
||||
perform Nix operations.</para>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
</section> <!-- end of multi-user -->
|
||||
|
||||
|
||||
</section> <!-- end of security -->
|
||||
|
||||
|
||||
<section><title>Using Nix</title>
|
||||
|
||||
<para>To use Nix, some environment variables should be set. In
|
||||
particular, <envar>PATH</envar> should contain the directories
|
||||
<filename><replaceable>prefix</replaceable>/bin</filename> and
|
||||
<filename>~/.nix-profile/bin</filename>. The first directory contains
|
||||
the Nix tools themselves, while <filename>~/.nix-profile</filename> is
|
||||
a symbolic link to the current <emphasis>user environment</emphasis>
|
||||
(an automatically generated package consisting of symlinks to
|
||||
installed packages). The simplest way to set the required environment
|
||||
variables is to include the file
|
||||
<filename><replaceable>prefix</replaceable>/etc/profile.d/nix.sh</filename>
|
||||
in your <filename>~/.bashrc</filename> (or similar), like this:</para>
|
||||
|
||||
<screen>
|
||||
source <replaceable>prefix</replaceable>/etc/profile.d/nix.sh</screen>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
</chapter>
|
||||
@@ -0,0 +1,49 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-building-source">
|
||||
|
||||
<title>Building Nix from Source</title>
|
||||
|
||||
<para>After unpacking or checking out the Nix sources, issue the
|
||||
following commands:
|
||||
|
||||
<screen>
|
||||
$ ./configure <replaceable>options...</replaceable>
|
||||
$ make
|
||||
$ make install</screen>
|
||||
|
||||
Nix requires GNU Make so you may need to invoke
|
||||
<command>gmake</command> instead.</para>
|
||||
|
||||
<para>When building from the Git repository, these should be preceded
|
||||
by the command:
|
||||
|
||||
<screen>
|
||||
$ ./bootstrap.sh</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>The installation path can be specified by passing the
|
||||
<option>--prefix=<replaceable>prefix</replaceable></option> to
|
||||
<command>configure</command>. The default installation directory is
|
||||
<filename>/usr/local</filename>. You can change this to any location
|
||||
you like. You must have write permission to the
|
||||
<replaceable>prefix</replaceable> path.</para>
|
||||
|
||||
<para>Nix keeps its <emphasis>store</emphasis> (the place where
|
||||
packages are stored) in <filename>/nix/store</filename> by default.
|
||||
This can be changed using
|
||||
<option>--with-store-dir=<replaceable>path</replaceable></option>.</para>
|
||||
|
||||
<warning><para>It is best <emphasis>not</emphasis> to change the Nix
|
||||
store from its default, since doing so makes it impossible to use
|
||||
pre-built binaries from the standard Nixpkgs channels — that is, all
|
||||
packages will need to be built from source.</para></warning>
|
||||
|
||||
<para>Nix keeps state (such as its database and log files) in
|
||||
<filename>/nix/var</filename> by default. This can be changed using
|
||||
<option>--localstatedir=<replaceable>path</replaceable></option>.</para>
|
||||
|
||||
</section>
|
||||
@@ -0,0 +1,24 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-env-variables">
|
||||
|
||||
<title>Environment Variables</title>
|
||||
|
||||
<para>To use Nix, some environment variables should be set. In
|
||||
particular, <envar>PATH</envar> should contain the directories
|
||||
<filename><replaceable>prefix</replaceable>/bin</filename> and
|
||||
<filename>~/.nix-profile/bin</filename>. The first directory contains
|
||||
the Nix tools themselves, while <filename>~/.nix-profile</filename> is
|
||||
a symbolic link to the current <emphasis>user environment</emphasis>
|
||||
(an automatically generated package consisting of symlinks to
|
||||
installed packages). The simplest way to set the required environment
|
||||
variables is to include the file
|
||||
<filename><replaceable>prefix</replaceable>/etc/profile.d/nix.sh</filename>
|
||||
in your <filename>~/.profile</filename> (or similar), like this:</para>
|
||||
|
||||
<screen>
|
||||
source <replaceable>prefix</replaceable>/etc/profile.d/nix.sh</screen>
|
||||
|
||||
</chapter>
|
||||
@@ -0,0 +1,34 @@
|
||||
<part xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="chap-installation">
|
||||
|
||||
<title>Installation</title>
|
||||
|
||||
<partintro>
|
||||
<para>This section describes how to install and configure Nix for first-time use.</para>
|
||||
</partintro>
|
||||
|
||||
<xi:include href="supported-platforms.xml" />
|
||||
<xi:include href="installing-binary.xml" />
|
||||
<xi:include href="installing-source.xml" />
|
||||
<xi:include href="nix-security.xml" />
|
||||
<xi:include href="env-variables.xml" />
|
||||
|
||||
<!-- TODO: should be updated
|
||||
<section><title>Upgrading Nix through Nix</title>
|
||||
|
||||
<para>You can install the latest stable version of Nix through Nix
|
||||
itself by subscribing to the channel <link
|
||||
xlink:href="http://nixos.org/releases/nix/channels/nix-stable" />,
|
||||
or the latest unstable version by subscribing to the channel <link
|
||||
xlink:href="http://nixos.org/releases/nix/channels/nix-unstable" />.
|
||||
You can also do a <link linkend="sec-one-click">one-click
|
||||
installation</link> by clicking on the package links at <link
|
||||
xlink:href="http://nixos.org/releases/full-index-nix.html" />.</para>
|
||||
|
||||
</section>
|
||||
-->
|
||||
|
||||
</part>
|
||||
@@ -0,0 +1,82 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-installing-binary">
|
||||
|
||||
<title>Installing a Binary Distribution</title>
|
||||
|
||||
<para>If you are using Linux or Mac OS X, the easiest way to install
|
||||
Nix is to run the following command:
|
||||
|
||||
<screen>
|
||||
$ bash <(curl https://nixos.org/nix/install)
|
||||
</screen>
|
||||
|
||||
This will perform a single-user installation of Nix, meaning that
|
||||
<filename>/nix</filename> is owned by the invoking user. You should
|
||||
run this under your usual user account, <emphasis>not</emphasis> as
|
||||
root. The script will invoke <command>sudo</command> to create
|
||||
<filename>/nix</filename> if it doesn’t already exist. If you don’t
|
||||
have <command>sudo</command>, you should manually create
|
||||
<command>/nix</command> first as root, e.g.:
|
||||
|
||||
<screen>
|
||||
$ mkdir /nix
|
||||
$ chown alice /nix
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>You can also manually download and install a binary package.
|
||||
Binary packages of the latest stable release are available for Fedora,
|
||||
Debian, Ubuntu, Mac OS X and various other systems from the <link
|
||||
xlink:href="http://nixos.org/nix/download.html">Nix homepage</link>.
|
||||
You can also get builds of the latest development release from our
|
||||
<link
|
||||
xlink:href="http://hydra.nixos.org/job/nix/master/release/latest-finished#tabs-constituents">continuous
|
||||
build system</link>.</para>
|
||||
|
||||
<para>For Fedora, RPM packages are available. These can be installed
|
||||
or upgraded using <command>rpm -U</command>. For example,
|
||||
|
||||
<screen>
|
||||
$ rpm -U nix-1.8-1.i386.rpm</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>For Debian and Ubuntu, you can download a Deb package and
|
||||
install it like this:
|
||||
|
||||
<screen>
|
||||
$ dpkg -i nix_1.8-1_amd64.deb</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>For other platforms, including Mac OS X and other Linux
|
||||
distributions, you can download a binary tarball that contains Nix and
|
||||
all its dependencies. (This is what the install script at
|
||||
<uri>https://nixos.org/nix/install</uri> uses.) You should unpack it
|
||||
somewhere (e.g. in <filename>/tmp</filename>), and then run the script
|
||||
named <command>install</command> inside the binary tarball:
|
||||
|
||||
<screen>
|
||||
alice$ cd /tmp
|
||||
alice$ tar xfj nix-1.8-x86_64-darwin.tar.bz2
|
||||
alice$ cd nix-1.8-x86_64-darwin
|
||||
alice$ ./install
|
||||
</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Nix can be uninstalled using <command>rpm -e nix</command> or
|
||||
<command>dpkg -r nix</command> on RPM- and Dpkg-based systems,
|
||||
respectively. After this you should manually remove the Nix store and
|
||||
other auxiliary data, if desired:
|
||||
|
||||
<screen>
|
||||
$ rm -rf /nix</screen>
|
||||
|
||||
</para>
|
||||
|
||||
</chapter>
|
||||
@@ -0,0 +1,16 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-installing-source">
|
||||
|
||||
<title>Installing Nix from Source</title>
|
||||
|
||||
<para>If no binary package is available, you can download and compile
|
||||
a source distribution.</para>
|
||||
|
||||
<xi:include href="prerequisites-source.xml" />
|
||||
<xi:include href="obtaining-source.xml" />
|
||||
<xi:include href="building-source.xml" />
|
||||
|
||||
</chapter>
|
||||
@@ -0,0 +1,107 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ssec-multi-user">
|
||||
|
||||
<title>Multi-User Mode</title>
|
||||
|
||||
<para>To allow a Nix store to be shared safely among multiple users,
|
||||
it is important that users are not able to run builders that modify
|
||||
the Nix store or database in arbitrary ways, or that interfere with
|
||||
builds started by other users. If they could do so, they could
|
||||
install a Trojan horse in some package and compromise the accounts of
|
||||
other users.</para>
|
||||
|
||||
<para>To prevent this, the Nix store and database are owned by some
|
||||
privileged user (usually <literal>root</literal>) and builders are
|
||||
executed under special user accounts (usually named
|
||||
<literal>nixbld1</literal>, <literal>nixbld2</literal>, etc.). When a
|
||||
unprivileged user runs a Nix command, actions that operate on the Nix
|
||||
store (such as builds) are forwarded to a <emphasis>Nix
|
||||
daemon</emphasis> running under the owner of the Nix store/database
|
||||
that performs the operation.</para>
|
||||
|
||||
<note><para>Multi-user mode has one important limitation: only
|
||||
<systemitem class="username">root</systemitem> and a set of trusted
|
||||
users specified in <filename>nix.conf</filename> can specify arbitrary
|
||||
binary caches. So while unprivileged users may install packages from
|
||||
arbitrary Nix expressions, they may not get pre-built
|
||||
binaries.</para></note>
|
||||
|
||||
|
||||
<simplesect>
|
||||
|
||||
<title>Setting up the build users</title>
|
||||
|
||||
<para>The <emphasis>build users</emphasis> are the special UIDs under
|
||||
which builds are performed. They should all be members of the
|
||||
<emphasis>build users group</emphasis> <literal>nixbld</literal>.
|
||||
This group should have no other members. The build users should not
|
||||
be members of any other group. On Linux, you can create the group and
|
||||
users as follows:
|
||||
|
||||
<screen>
|
||||
$ groupadd -r nixbld
|
||||
$ for n in $(seq 1 10); do useradd -c "Nix build user $n" \
|
||||
-d /var/empty -g nixbld -G nixbld -M -N -r -s "$(which nologin)" \
|
||||
nixbld$n; done
|
||||
</screen>
|
||||
|
||||
This creates 10 build users. There can never be more concurrent builds
|
||||
than the number of build users, so you may want to increase this if
|
||||
you expect to do many builds at the same time.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect>
|
||||
|
||||
<title>Running the daemon</title>
|
||||
|
||||
<para>The <link linkend="sec-nix-daemon">Nix daemon</link> should be
|
||||
started as follows (as <literal>root</literal>):
|
||||
|
||||
<screen>
|
||||
$ nix-daemon</screen>
|
||||
|
||||
You’ll want to put that line somewhere in your system’s boot
|
||||
scripts.</para>
|
||||
|
||||
<para>To let unprivileged users use the daemon, they should set the
|
||||
<link linkend="envar-remote"><envar>NIX_REMOTE</envar> environment
|
||||
variable</link> to <literal>daemon</literal>. So you should put a
|
||||
line like
|
||||
|
||||
<programlisting>
|
||||
export NIX_REMOTE=daemon</programlisting>
|
||||
|
||||
into the users’ login scripts.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect>
|
||||
|
||||
<title>Restricting access</title>
|
||||
|
||||
<para>To limit which users can perform Nix operations, you can use the
|
||||
permissions on the directory
|
||||
<filename>/nix/var/nix/daemon-socket</filename>. For instance, if you
|
||||
want to restrict the use of Nix to the members of a group called
|
||||
<literal>nix-users</literal>, do
|
||||
|
||||
<screen>
|
||||
$ chgrp nix-users /nix/var/nix/daemon-socket
|
||||
$ chmod ug=rwx,o= /nix/var/nix/daemon-socket
|
||||
</screen>
|
||||
|
||||
This way, users who are not in the <literal>nix-users</literal> group
|
||||
cannot connect to the Unix domain socket
|
||||
<filename>/nix/var/nix/daemon-socket/socket</filename>, so they cannot
|
||||
perform Nix operations.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
</section>
|
||||
@@ -0,0 +1,27 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-nix-security">
|
||||
|
||||
<title>Security</title>
|
||||
|
||||
<para>Nix has two basic security models. First, it can be used in
|
||||
“single-user mode”, which is similar to what most other package
|
||||
management tools do: there is a single user (typically <systemitem
|
||||
class="username">root</systemitem>) who performs all package
|
||||
management operations. All other users can then use the installed
|
||||
packages, but they cannot perform package management operations
|
||||
themselves.</para>
|
||||
|
||||
<para>Alternatively, you can configure Nix in “multi-user mode”. In
|
||||
this model, all users can perform package management operations — for
|
||||
instance, every user can install software without requiring root
|
||||
privileges. Nix ensures that this is secure. For instance, it’s not
|
||||
possible for one user to overwrite a package used by another user with
|
||||
a Trojan horse.</para>
|
||||
|
||||
<xi:include href="single-user.xml" />
|
||||
<xi:include href="multi-user.xml" />
|
||||
|
||||
</chapter>
|
||||
@@ -0,0 +1,30 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-obtaining-source">
|
||||
|
||||
<title>Obtaining a Source Distribution</title>
|
||||
|
||||
<para>The source tarball of the most recent stable release can be
|
||||
downloaded from the <link
|
||||
xlink:href="http://nixos.org/nix/download.html">Nix homepage</link>.
|
||||
You can also grab the <link
|
||||
xlink:href="http://hydra.nixos.org/job/nix/master/release/latest-finished#tabs-constituents">most
|
||||
recent development release</link>.</para>
|
||||
|
||||
<para>Alternatively, the most recent sources of Nix can be obtained
|
||||
from its <link
|
||||
xlink:href="https://github.com/NixOS/nix">Git
|
||||
repository</link>. For example, the following command will check out
|
||||
the latest revision into a directory called
|
||||
<filename>nix</filename>:</para>
|
||||
|
||||
<screen>
|
||||
$ git clone https://github.com/NixOS/nix</screen>
|
||||
|
||||
<para>Likewise, specific releases can be obtained from the <link
|
||||
xlink:href="https://github.com/NixOS/nix/tags">tags</link> of the
|
||||
repository.</para>
|
||||
|
||||
</section>
|
||||
@@ -0,0 +1,73 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-prerequisites-source">
|
||||
|
||||
<title>Prerequisites</title>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para>GNU Make.</para></listitem>
|
||||
|
||||
<listitem><para>A version of GCC or Clang that supports C++11.</para></listitem>
|
||||
|
||||
<listitem><para>Perl 5.8 or higher.</para></listitem>
|
||||
|
||||
<listitem><para><command>pkg-config</command> to locate
|
||||
dependencies. If your distribution does not provide it, you can get
|
||||
it from <link
|
||||
xlink:href="http://www.freedesktop.org/wiki/Software/pkg-config"
|
||||
/>.</para></listitem>
|
||||
|
||||
<listitem><para>The bzip2 compressor program and the
|
||||
<literal>libbz2</literal> library. Thus you must have bzip2
|
||||
installed, including development headers and libraries. If your
|
||||
distribution does not provide these, you can obtain bzip2 from <link
|
||||
xlink:href="http://www.bzip.org/"/>.</para></listitem>
|
||||
|
||||
<listitem><para>The SQLite embedded database library, version 3.6.19
|
||||
or higher. If your distribution does not provide it, please install
|
||||
it from <link xlink:href="http://www.sqlite.org/" />.</para></listitem>
|
||||
|
||||
<listitem><para>The Perl DBI and DBD::SQLite libraries, which are
|
||||
available from <link
|
||||
xlink:href="http://search.cpan.org/">CPAN</link> if your
|
||||
distribution does not provide them.</para></listitem>
|
||||
|
||||
<listitem><para>The <link
|
||||
xlink:href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/">Boehm
|
||||
garbage collector</link> to reduce the evaluator’s memory
|
||||
consumption (optional). To enable it, install
|
||||
<literal>pkgconfig</literal> and the Boehm garbage collector, and
|
||||
pass the flag <option>--enable-gc</option> to
|
||||
<command>configure</command>.</para></listitem>
|
||||
|
||||
<listitem><para>The <command>xmllint</command> and
|
||||
<command>xsltproc</command> programs to build this manual and the
|
||||
man-pages. These are part of the <literal>libxml2</literal> and
|
||||
<literal>libxslt</literal> packages, respectively. You also need
|
||||
the <link
|
||||
xlink:href="http://docbook.sourceforge.net/projects/xsl/">DocBook
|
||||
XSL stylesheets</link> and optionally the <link
|
||||
xlink:href="http://www.docbook.org/schemas/5x"> DocBook 5.0 RELAX NG
|
||||
schemas</link>. Note that these are only required if you modify the
|
||||
manual sources or when you are building from the Git
|
||||
repository.</para></listitem>
|
||||
|
||||
<listitem><para>Recent versions of Bison and Flex to build the
|
||||
parser. (This is because Nix needs GLR support in Bison and
|
||||
reentrancy support in Flex.) For Bison, you need version 2.6, which
|
||||
can be obtained from the <link
|
||||
xlink:href="ftp://alpha.gnu.org/pub/gnu/bison">GNU FTP
|
||||
server</link>. For Flex, you need version 2.5.35, which is
|
||||
available on <link
|
||||
xlink:href="http://lex.sourceforge.net/">SourceForge</link>.
|
||||
Slightly older versions may also work, but ancient versions like the
|
||||
ubiquitous 2.5.4a won't. Note that these are only required if you
|
||||
modify the parser or when you are building from the Git
|
||||
repository.</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</section>
|
||||
@@ -0,0 +1,21 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="sec-single-user">
|
||||
|
||||
<title>Single-User Mode</title>
|
||||
|
||||
<para>In single-user mode, all Nix operations that access the database
|
||||
in <filename><replaceable>prefix</replaceable>/var/nix/db</filename>
|
||||
or modify the Nix store in
|
||||
<filename><replaceable>prefix</replaceable>/store</filename> must be
|
||||
performed under the user ID that owns those directories. This is
|
||||
typically <systemitem class="username">root</systemitem>. (If you
|
||||
install from RPM packages, that’s in fact the default ownership.)
|
||||
However, on single-user machines, it is often convenient to
|
||||
<command>chown</command> those directories to your normal user account
|
||||
so that you don’t have to <command>su</command> to <systemitem
|
||||
class="username">root</systemitem> all the time.</para>
|
||||
|
||||
</section>
|
||||
@@ -0,0 +1,39 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-supported-platforms">
|
||||
|
||||
<title>Supported Platforms</title>
|
||||
|
||||
<para>Nix is currently supported on the following platforms:
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para>Linux (i686, x86_64).</para></listitem>
|
||||
|
||||
<listitem><para>Mac OS X (x86_64).</para></listitem>
|
||||
|
||||
<!--
|
||||
<listitem><para>FreeBSD (only tested on Intel).</para></listitem>
|
||||
-->
|
||||
|
||||
<!--
|
||||
<listitem><para>Windows through <link
|
||||
xlink:href="http://www.cygwin.com/">Cygwin</link>.</para>
|
||||
|
||||
<warning><para>On Cygwin, Nix <emphasis>must</emphasis> be installed
|
||||
on an NTFS partition. It will not work correctly on a FAT
|
||||
partition.</para></warning>
|
||||
|
||||
</listitem>
|
||||
-->
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Nix is fairly portable, so it should work on most platforms that
|
||||
support POSIX threads and have a C++11 compiler.</para>
|
||||
|
||||
</chapter>
|
||||
@@ -1,11 +1,10 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id="chap-introduction">
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="ch-about-nix">
|
||||
|
||||
<title>Introduction</title>
|
||||
|
||||
|
||||
<section><title>About Nix</title>
|
||||
<title>About Nix</title>
|
||||
|
||||
<para>Nix is a <emphasis>purely functional package manager</emphasis>.
|
||||
This means that it treats packages like values in purely functional
|
||||
@@ -17,10 +16,10 @@ store</emphasis>, usually the directory
|
||||
subdirectory such as
|
||||
|
||||
<programlisting>
|
||||
/nix/store/nlc4z5y1hm8w9s8vm6m1f5hy962xjmp5-firefox-12.0
|
||||
/nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/
|
||||
</programlisting>
|
||||
|
||||
where <literal>nlc4z5…</literal> is a unique identifier for the
|
||||
where <literal>b6gvzjyb2pg0…</literal> is a unique identifier for the
|
||||
package that captures all its dependencies (it’s a cryptographic hash
|
||||
of the package’s build dependency graph). This enables many powerful
|
||||
features.</para>
|
||||
@@ -81,11 +80,6 @@ package won’t be built or downloaded a second time. At the same time,
|
||||
it is not possible for one user to inject a Trojan horse into a
|
||||
package that might be used by another user.</para>
|
||||
|
||||
<!--
|
||||
<para>More details can be found in Section 3 of our <a
|
||||
href="docs/papers.html#securesharing">ASE 2005 paper</a>.</para>
|
||||
-->
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
@@ -167,19 +161,19 @@ library and the compiler) would have to built, at least if they are
|
||||
not already in the Nix store. This is a <emphasis>source deployment
|
||||
model</emphasis>. For most users, building from source is not very
|
||||
pleasant as it takes far too long. However, Nix can automatically
|
||||
skip building from source and download a pre-built binary instead if
|
||||
it knows about it. <emphasis>Nix channels</emphasis> provide Nix
|
||||
expressions along with pre-built binaries.</para>
|
||||
|
||||
<!--
|
||||
<para>source deployment model (like <a
|
||||
href="http://www.gentoo.org/">Gentoo</a>) and a binary model (like
|
||||
RPM)</para>
|
||||
-->
|
||||
skip building from source and instead use a <emphasis>binary
|
||||
cache</emphasis>, a web server that provides pre-built binaries. For
|
||||
instance, when asked to build
|
||||
<literal>/nix/store/b6gvzjyb2pg0…-firefox-33.1</literal> from source,
|
||||
Nix would first check if the file
|
||||
<uri>https://cache.nixos.org/b6gvzjyb2pg0….narinfo</uri> exists, and
|
||||
if so, fetch the pre-built binary referenced from there; otherwise, it
|
||||
would fall back to building from source.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<!--
|
||||
<simplesect><title>Binary patching</title>
|
||||
|
||||
<para>In addition to downloading binaries automatically if they’re
|
||||
@@ -188,6 +182,7 @@ package in the Nix store into a new version. This speeds up
|
||||
upgrades.</para>
|
||||
|
||||
</simplesect>
|
||||
-->
|
||||
|
||||
|
||||
<simplesect><title>Nix Packages collection</title>
|
||||
@@ -199,24 +194,40 @@ collection</emphasis> (Nixpkgs).</para>
|
||||
</simplesect>
|
||||
|
||||
|
||||
<simplesect><title>Service deployment</title>
|
||||
<simplesect><title>Managing build environments</title>
|
||||
|
||||
<para>Nix can be used not only for rolling out packages, but also
|
||||
complete <emphasis>configurations</emphasis> of services. This is
|
||||
done by treating all the static bits of a service (such as software
|
||||
packages, configuration files, control scripts, static web pages,
|
||||
etc.) as “packages” that can be built by Nix expressions. As a
|
||||
result, all the features above apply to services as well: for
|
||||
instance, you can roll back a web server configuration if a
|
||||
configuration change turns out to be undesirable, you can easily have
|
||||
multiple instances of a service (e.g., a test and production server),
|
||||
and because the whole service is built in a purely functional way from
|
||||
a Nix expression, it is repeatable so you can easily reproduce the
|
||||
service on another machine.</para>
|
||||
<para>Nix is extremely useful for developers as it makes it easy to
|
||||
automatically set up the the build environment for a package. Given a
|
||||
Nix expression that describes the dependencies of your package, the
|
||||
command <command>nix-shell</command> will build or download those
|
||||
dependencies if they’re not already in your Nix store, and then start
|
||||
a Bash shell in which all necessary environment variables (such as
|
||||
compiler search paths) are set.</para>
|
||||
|
||||
<para>For example, the following command gets all dependencies of the
|
||||
Pan newsreader, as described by <link
|
||||
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/newsreaders/pan/default.nix">its
|
||||
Nix expression</link>:</para>
|
||||
|
||||
<screen>
|
||||
$ nix-shell '<nixpkgs>' -A pan
|
||||
</screen>
|
||||
|
||||
<para>You’re then dropped into a shell where you can edit, build and test
|
||||
the package:</para>
|
||||
|
||||
<screen>
|
||||
[nix-shell]$ tar xf $src
|
||||
[nix-shell]$ cd pan-*
|
||||
[nix-shell]$ ./configure
|
||||
[nix-shell]$ make
|
||||
[nix-shell]$ ./pan/gui/pan
|
||||
</screen>
|
||||
|
||||
<!--
|
||||
<para>You can read more about this in our <a
|
||||
href="docs/papers.html#servicecm">SCM-12 paper</a>.</para>
|
||||
<para>Since Nix packages are reproducible and have complete dependency
|
||||
specifications, Nix makes an excellent basis for <a
|
||||
href="[%root%]hydra">a continuous build system</a>.</para>
|
||||
-->
|
||||
|
||||
</simplesect>
|
||||
@@ -224,8 +235,7 @@ href="docs/papers.html#servicecm">SCM-12 paper</a>.</para>
|
||||
|
||||
<simplesect><title>Portability</title>
|
||||
|
||||
<para>Nix should run on most Unix systems, including Linux, FreeBSD and
|
||||
Mac OS X.<!-- It is also supported on Windows using Cygwin.--></para>
|
||||
<para>Nix runs on Linux and Mac OS X.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
@@ -235,103 +245,22 @@ Mac OS X.<!-- It is also supported on Windows using Cygwin.--></para>
|
||||
<para>NixOS is a Linux distribution based on Nix. It uses Nix not
|
||||
just for package management but also to manage the system
|
||||
configuration (e.g., to build configuration files in
|
||||
<filename>/etc</filename>). This means, among other things, that it’s
|
||||
possible to easily roll back the entire configuration of the system to
|
||||
an earlier state. Also, users can install software without root
|
||||
<filename>/etc</filename>). This means, among other things, that it
|
||||
is easy to roll back the entire configuration of the system to an
|
||||
earlier state. Also, users can install software without root
|
||||
privileges. For more information and downloads, see the <link
|
||||
xlink:href="http://nixos.org/">NixOS homepage</link>.</para>
|
||||
|
||||
</simplesect>
|
||||
|
||||
|
||||
<!-- other features:
|
||||
<simplesect><title>License</title>
|
||||
|
||||
- build farms
|
||||
- reproducibility (Nix expressions allows whole configuration to be rebuilt)
|
||||
<para>Nix is released under the terms of the <link
|
||||
xlink:href="http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html">GNU
|
||||
LGPLv2.1 or (at your option) any later version</link>.</para>
|
||||
|
||||
-->
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<section><title>About us</title>
|
||||
|
||||
<para>Nix was originally developed at the <link
|
||||
xlink:href="http://www.cs.uu.nl/">Department of Information and
|
||||
Computing Sciences</link>, Utrecht University by the <link
|
||||
xlink:href="http://www.cs.uu.nl/wiki/Trace/WebHome">TraCE
|
||||
project</link> (2003-2008). The project was funded by the Software
|
||||
Engineering Research Program <link
|
||||
xlink:href="http://www.jacquard.nl/">Jacquard</link> to improve the
|
||||
support for variability in software systems. Further funding was
|
||||
provided by the NIRICT LaQuSo Build Farm project. Development is
|
||||
currently supported by <link
|
||||
xlink:href="http://www.logicblox.com/">LogicBlox</link>.</para>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<section><title>About this manual</title>
|
||||
|
||||
<para>This manual tells you how to install and use Nix and how to
|
||||
write Nix expressions for software not already in the Nix Packages
|
||||
collection. It also discusses some advanced topics, such as setting
|
||||
up distributed multi-platform building.</para>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<section><title>License</title>
|
||||
|
||||
<para>Nix is free software; you can redistribute it and/or modify it
|
||||
under the terms of the <link
|
||||
xlink:href="http://www.gnu.org/licenses/lgpl.html">GNU Lesser General
|
||||
Public License</link> as published by the <link
|
||||
xlink:href="http://www.fsf.org/">Free Software Foundation</link>;
|
||||
either version 2.1 of the License, or (at your option) any later
|
||||
version. Nix is distributed in the hope that it will be useful, but
|
||||
WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
||||
Lesser General Public License for more details.</para>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<section><title>More information</title>
|
||||
|
||||
<para>Some background information on Nix can be found in a number of
|
||||
papers. The ICSE 2004 paper <citetitle
|
||||
xlink:href='http://www.st.ewi.tudelft.nl/~dolstra/pubs/immdsd-icse2004-final.pdf'>Imposing
|
||||
a Memory Management Discipline on Software Deployment</citetitle>
|
||||
discusses the hashing mechanism used to ensure reliable dependency
|
||||
identification and non-interference between different versions and
|
||||
variants of packages. The LISA 2004 paper <citetitle
|
||||
xlink:href='http://www.st.ewi.tudelft.nl/~dolstra/pubs/nspfssd-lisa2004-final.pdf'>Nix:
|
||||
A Safe and Policy-Free System for Software Deployment</citetitle>
|
||||
gives a more general discussion of Nix from a system-administration
|
||||
perspective. The CBSE 2005 paper <citetitle
|
||||
xlink:href='http://www.st.ewi.tudelft.nl/~dolstra/pubs/eupfcdm-cbse2005-final.pdf'>Efficient
|
||||
Upgrading in a Purely Functional Component Deployment Model
|
||||
</citetitle> is about transparent patch deployment in Nix. The SCM-12
|
||||
paper <citetitle
|
||||
xlink:href='http://www.st.ewi.tudelft.nl/~dolstra/pubs/servicecm-scm12-final.pdf'>
|
||||
Service Configuration Management</citetitle> shows how services (e.g.,
|
||||
web servers) can be deployed and managed through Nix. An overview of
|
||||
NixOS is given in the JFP article <citetitle
|
||||
xlink:href="http://www.st.ewi.tudelft.nl/~dolstra/pubs/nixos-jfp-final.pdf">NixOS:
|
||||
A Purely Functional Linux Distribution</citetitle>. The Nix homepage
|
||||
has <link xlink:href="http://nixos.org/docs/papers.html">an up-to-date
|
||||
list of Nix-related papers</link>.</para>
|
||||
|
||||
<para>Nix is the subject of Eelco Dolstra’s PhD thesis <citetitle
|
||||
xlink:href="http://igitur-archive.library.uu.nl/dissertations/2006-0118-200031/index.htm">The
|
||||
Purely Functional Software Deployment Model</citetitle>, which
|
||||
contains most of the papers listed above.</para>
|
||||
|
||||
<para>Nix has a homepage at <link
|
||||
xlink:href="http://nixos.org/"/>.</para>
|
||||
|
||||
</section>
|
||||
</simplesect>
|
||||
|
||||
|
||||
</chapter>
|
||||
@@ -0,0 +1,12 @@
|
||||
<part xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="chap-introduction">
|
||||
|
||||
<title>Introduction</title>
|
||||
|
||||
<xi:include href="about-nix.xml" />
|
||||
<xi:include href="quick-start.xml" />
|
||||
|
||||
</part>
|
||||
@@ -0,0 +1,136 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="chap-quick-start">
|
||||
|
||||
<title>Quick Start</title>
|
||||
|
||||
<para>This chapter is for impatient people who don't like reading
|
||||
documentation. For more in-depth information you are kindly referred
|
||||
to subsequent chapters.</para>
|
||||
|
||||
<procedure>
|
||||
|
||||
<step><para>Install single-user Nix by running the following:
|
||||
|
||||
<screen>
|
||||
$ curl https://nixos.org/nix/install | sh
|
||||
</screen>
|
||||
|
||||
This will install Nix in <filename>/nix</filename>. The install script
|
||||
will create <filename>/nix</filename> using <command>sudo</command>,
|
||||
so make sure you have sufficient rights. (For other installation
|
||||
methods, see <xref linkend="chap-installation"/>.)</para></step>
|
||||
|
||||
<step><para>See what installable packages are currently available
|
||||
in the channel:
|
||||
|
||||
<screen>
|
||||
$ nix-env -qa
|
||||
docbook-xml-4.3
|
||||
docbook-xml-4.5
|
||||
firefox-33.0.2
|
||||
hello-2.9
|
||||
libxslt-1.1.28
|
||||
<replaceable>...</replaceable></screen>
|
||||
|
||||
</para></step>
|
||||
|
||||
<step><para>Install some packages from the channel:
|
||||
|
||||
<screen>
|
||||
$ nix-env -i hello <replaceable>...</replaceable> </screen>
|
||||
|
||||
This should download pre-built packages; it should not build them
|
||||
locally (if it does, something went wrong).</para></step>
|
||||
|
||||
<step><para>Test that they work:
|
||||
|
||||
<screen>
|
||||
$ which hello
|
||||
/home/eelco/.nix-profile/bin/hello
|
||||
$ hello
|
||||
Hello, world!
|
||||
</screen>
|
||||
|
||||
</para></step>
|
||||
|
||||
<step><para>Uninstall a package:
|
||||
|
||||
<screen>
|
||||
$ nix-env -e hello</screen>
|
||||
|
||||
</para></step>
|
||||
|
||||
<step><para>You can also test a package without installing it:
|
||||
|
||||
<screen>
|
||||
$ nix-shell -p hello
|
||||
</screen>
|
||||
|
||||
This builds or downloads GNU Hello and its dependencies, then drops
|
||||
you into a Bash shell where the <command>hello</command> command is
|
||||
present, all without affecting your normal environment:
|
||||
|
||||
<screen>
|
||||
[nix-shell:~]$ hello
|
||||
Hello, world!
|
||||
|
||||
[nix-shell:~]$ exit
|
||||
|
||||
$ hello
|
||||
hello: command not found
|
||||
</screen>
|
||||
|
||||
</para></step>
|
||||
|
||||
<step><para>To keep up-to-date with the channel, do:
|
||||
|
||||
<screen>
|
||||
$ nix-channel --update nixpkgs
|
||||
$ nix-env -u '*'</screen>
|
||||
|
||||
The latter command will upgrade each installed package for which there
|
||||
is a “newer” version (as determined by comparing the version
|
||||
numbers).</para></step>
|
||||
|
||||
<!--
|
||||
<step><para>You can also install specific packages directly from
|
||||
your web browser. For instance, you can go to <link
|
||||
xlink:href="http://hydra.nixos.org/jobset/nixpkgs/trunk/channel/latest"
|
||||
/> and click on any link for the individual packages for your
|
||||
platform. Associate <literal>application/nix-package</literal> with
|
||||
the program <command>nix-install-package</command>. A window should
|
||||
appear asking you whether it’s okay to install the package. Say
|
||||
<literal>Y</literal>. The package and all its dependencies will be
|
||||
installed.</para></step>
|
||||
-->
|
||||
|
||||
<step><para>If you're unhappy with the result of a
|
||||
<command>nix-env</command> action (e.g., an upgraded package turned
|
||||
out not to work properly), you can go back:
|
||||
|
||||
<screen>
|
||||
$ nix-env --rollback</screen>
|
||||
|
||||
</para></step>
|
||||
|
||||
<step><para>You should periodically run the Nix garbage collector
|
||||
to get rid of unused packages, since uninstalls or upgrades don't
|
||||
actually delete them:
|
||||
|
||||
<screen>
|
||||
$ nix-collect-garbage -d</screen>
|
||||
|
||||
<!--
|
||||
The first command deletes old “generations” of your profile (making
|
||||
rollbacks impossible, but also making the packages in those old
|
||||
generations available for garbage collection), while the second
|
||||
command actually deletes them.-->
|
||||
|
||||
</para></step>
|
||||
|
||||
</procedure>
|
||||
|
||||
</chapter>
|
||||
@@ -0,0 +1,92 @@
|
||||
XSLTPROC = $(xsltproc) --nonet $(xmlflags) \
|
||||
--param section.autolabel 1 \
|
||||
--param section.label.includes.component.label 1 \
|
||||
--param html.stylesheet \'style.css\' \
|
||||
--param xref.with.number.and.title 1 \
|
||||
--param toc.section.depth 3 \
|
||||
--param admon.style \'\' \
|
||||
--param callout.graphics.extension \'.gif\' \
|
||||
--param contrib.inline.enabled 0 \
|
||||
--stringparam generate.toc "book toc" \
|
||||
--param keep.relative.image.uris 0
|
||||
|
||||
docbookxsl = http://docbook.sourceforge.net/release/xsl-ns/1.78.1
|
||||
docbookrng = http://docbook.org/xml/5.0/rng/docbook.rng
|
||||
|
||||
MANUAL_SRCS := $(call rwildcard, $(d), *.xml)
|
||||
|
||||
|
||||
# Do XInclude processing / RelaxNG validation
|
||||
$(d)/manual.xmli: $(d)/manual.xml $(MANUAL_SRCS) $(d)/version.txt
|
||||
$(trace-gen) $(xmllint) --nonet --xinclude $< -o $@.tmp
|
||||
@mv $@.tmp $@
|
||||
|
||||
$(d)/version.txt:
|
||||
$(trace-gen) echo -n $(PACKAGE_VERSION) > $@
|
||||
|
||||
# Note: RelaxNG validation requires xmllint >= 2.7.4.
|
||||
$(d)/manual.is-valid: $(d)/manual.xmli
|
||||
$(trace-gen) $(XSLTPROC) --novalid --stringparam profile.condition manual \
|
||||
$(docbookxsl)/profiling/profile.xsl $< 2> /dev/null | \
|
||||
$(xmllint) --nonet --noout --relaxng $(docbookrng) -
|
||||
@touch $@
|
||||
|
||||
clean-files += $(d)/manual.xmli $(d)/version.txt $(d)/manual.is-valid
|
||||
|
||||
dist-files += $(d)/manual.xmli $(d)/version.txt $(d)/manual.is-valid
|
||||
|
||||
|
||||
# Generate man pages.
|
||||
man-pages := $(foreach n, \
|
||||
nix-env.1 nix-build.1 nix-shell.1 nix-store.1 nix-instantiate.1 \
|
||||
nix-collect-garbage.1 nix-push.1 nix-pull.1 \
|
||||
nix-prefetch-url.1 nix-channel.1 \
|
||||
nix-install-package.1 nix-hash.1 nix-copy-closure.1 \
|
||||
nix.conf.5 nix-daemon.8, \
|
||||
$(d)/$(n))
|
||||
|
||||
$(firstword $(man-pages)): $(d)/manual.xmli $(d)/manual.is-valid
|
||||
$(trace-gen) $(XSLTPROC) --novalid --stringparam profile.condition manpage \
|
||||
$(docbookxsl)/profiling/profile.xsl $< 2> /dev/null | \
|
||||
(cd doc/manual && $(XSLTPROC) $(docbookxsl)/manpages/docbook.xsl -)
|
||||
|
||||
$(wordlist 2, $(words $(man-pages)), $(man-pages)): $(firstword $(man-pages))
|
||||
|
||||
clean-files += $(d)/*.1 $(d)/*.5 $(d)/*.8
|
||||
|
||||
dist-files += $(man-pages)
|
||||
|
||||
|
||||
# Generate the HTML manual.
|
||||
$(d)/manual.html: $(d)/manual.xml $(MANUAL_SRCS) $(d)/manual.is-valid
|
||||
$(trace-gen) $(XSLTPROC) --xinclude --stringparam profile.condition manual \
|
||||
$(docbookxsl)/profiling/profile.xsl $< | \
|
||||
$(XSLTPROC) --output $@ $(docbookxsl)/xhtml/docbook.xsl -
|
||||
|
||||
$(foreach file, $(d)/manual.html $(d)/style.css, $(eval $(call install-data-in, $(file), $(docdir)/manual)))
|
||||
|
||||
$(foreach file, $(wildcard $(d)/figures/*.png), $(eval $(call install-data-in, $(file), $(docdir)/manual/figures)))
|
||||
|
||||
$(foreach file, $(wildcard $(d)/images/callouts/*.gif), $(eval $(call install-data-in, $(file), $(docdir)/manual/images/callouts)))
|
||||
|
||||
$(eval $(call install-symlink, manual.html, $(docdir)/manual/index.html))
|
||||
|
||||
all: $(d)/manual.html
|
||||
|
||||
clean-files += $(d)/manual.html
|
||||
|
||||
dist-files += $(d)/manual.html
|
||||
|
||||
|
||||
# Generate the PDF manual.
|
||||
$(d)/manual.pdf: $(d)/manual.xml $(MANUAL_SRCS) $(d)/manual.is-valid
|
||||
$(trace-gen) if test "$(dblatex)" != ""; then \
|
||||
cd doc/manual && $(XSLTPROC) --xinclude --stringparam profile.condition manual \
|
||||
$(docbookxsl)/profiling/profile.xsl manual.xml | \
|
||||
$(dblatex) -o $(notdir $@) $(dblatex_opts) -; \
|
||||
else \
|
||||
echo "Please install dblatex and rerun configure."; \
|
||||
exit 1; \
|
||||
fi
|
||||
|
||||
clean-files += $(d)/manual.pdf
|
||||
@@ -1,9 +1,11 @@
|
||||
<book xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude">
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0">
|
||||
|
||||
<info>
|
||||
|
||||
<title>Nix User's Guide</title>
|
||||
<title>Nix Package Manager Guide</title>
|
||||
|
||||
<edition>Version <xi:include href="version.txt" parse="text" /></edition>
|
||||
|
||||
@@ -19,64 +21,39 @@
|
||||
</author>
|
||||
|
||||
<copyright>
|
||||
<year>2004-2012</year>
|
||||
<year>2004-2014</year>
|
||||
<holder>Eelco Dolstra</holder>
|
||||
</copyright>
|
||||
|
||||
<date>May 2012</date>
|
||||
|
||||
<date>November 2014</date>
|
||||
|
||||
</info>
|
||||
|
||||
|
||||
<xi:include href="introduction.xml" />
|
||||
<xi:include href="quick-start.xml" />
|
||||
<xi:include href="installation.xml" />
|
||||
<xi:include href="package-management.xml" />
|
||||
<xi:include href="writing-nix-expressions.xml" />
|
||||
<xi:include href="build-farm.xml" />
|
||||
<!--
|
||||
<preface>
|
||||
<title>Preface</title>
|
||||
<para>This manual describes how to set up and use the Nix package
|
||||
manager.</para>
|
||||
</preface>
|
||||
-->
|
||||
|
||||
<xi:include href="introduction/introduction.xml" />
|
||||
<xi:include href="installation/installation.xml" />
|
||||
<xi:include href="packages/package-management.xml" />
|
||||
<xi:include href="expressions/writing-nix-expressions.xml" />
|
||||
<xi:include href="advanced-topics/advanced-topics.xml" />
|
||||
<xi:include href="command-ref/command-ref.xml" />
|
||||
<xi:include href="troubleshooting/troubleshooting.xml" />
|
||||
<xi:include href="glossary/glossary.xml" />
|
||||
<xi:include href="hacking.xml" />
|
||||
<xi:include href="release-notes/release-notes.xml" />
|
||||
|
||||
<appendix>
|
||||
<title>Command Reference</title>
|
||||
<xi:include href="opt-common.xml" />
|
||||
<xi:include href="env-common.xml" />
|
||||
|
||||
<section>
|
||||
<title>Main commands</title>
|
||||
<xi:include href="nix-env.xml" />
|
||||
<xi:include href="nix-instantiate.xml" />
|
||||
<xi:include href="nix-store.xml" />
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Utilities</title>
|
||||
<xi:include href="nix-build.xml" />
|
||||
<xi:include href="nix-channel.xml" />
|
||||
<xi:include href="nix-collect-garbage.xml" />
|
||||
<xi:include href="nix-copy-closure.xml" />
|
||||
<xi:include href="nix-hash.xml" />
|
||||
<xi:include href="nix-install-package.xml" />
|
||||
<xi:include href="nix-prefetch-url.xml" />
|
||||
<xi:include href="nix-pull.xml" />
|
||||
<xi:include href="nix-push.xml" />
|
||||
<xi:include href="nix-daemon.xml" />
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Files</title>
|
||||
<xi:include href="conf-file.xml" />
|
||||
</section>
|
||||
|
||||
</appendix>
|
||||
|
||||
<xi:include href="troubleshooting.xml" />
|
||||
<!-- <xi:include href="bugs.xml" /> -->
|
||||
<xi:include href="glossary.xml" />
|
||||
|
||||
<appendix>
|
||||
<!--
|
||||
<appendix>
|
||||
<title>Nix Release Notes</title>
|
||||
<xi:include href="release-notes.xml"
|
||||
<xi:include href="release-notes/release-notes.xml"
|
||||
xpointer="xmlns(x=http://docbook.org/ns/docbook)xpointer(x:article/x:section)" />
|
||||
</appendix>
|
||||
|
||||
-->
|
||||
|
||||
</book>
|
||||
|
||||
@@ -1,112 +0,0 @@
|
||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-nix-channel">
|
||||
|
||||
<refmeta>
|
||||
<refentrytitle>nix-channel</refentrytitle>
|
||||
<manvolnum>1</manvolnum>
|
||||
<refmiscinfo class="source">Nix</refmiscinfo>
|
||||
<refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo>
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>nix-channel</refname>
|
||||
<refpurpose>manage Nix channels</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<cmdsynopsis>
|
||||
<command>nix-channel</command>
|
||||
<group choice='req'>
|
||||
<arg choice='plain'><option>--add</option> <replaceable>url</replaceable> <arg choice='opt'><replaceable>name</replaceable></arg></arg>
|
||||
<arg choice='plain'><option>--remove</option> <replaceable>url</replaceable></arg>
|
||||
<arg choice='plain'><option>--list</option></arg>
|
||||
<arg choice='plain'><option>--update</option> <arg rep='repeat'><replaceable>names</replaceable></arg></arg>
|
||||
</group>
|
||||
</cmdsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsection><title>Description</title>
|
||||
|
||||
<para>A Nix channel is mechanism that allows you to automatically stay
|
||||
up-to-date with a set of pre-built Nix expressions. A Nix channel is
|
||||
just a URL that points to a place containing a set of Nix expressions
|
||||
and a <command>nix-push</command> manifest. <phrase
|
||||
condition="manual">See also <xref linkend="sec-channels"
|
||||
/>.</phrase></para>
|
||||
|
||||
<para>This command has the following operations:
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry><term><option>--add</option> <replaceable>url</replaceable> [<replaceable>name</replaceable>]</term>
|
||||
|
||||
<listitem><para>Adds a channel named
|
||||
<replaceable>name</replaceable> with URL
|
||||
<replaceable>url</replaceable> to the list of subscribed channels.
|
||||
If <replaceable>name</replaceable> is omitted, it defaults to the
|
||||
last component of <replaceable>url</replaceable>, with the
|
||||
suffixes <literal>-stable</literal> or
|
||||
<literal>-unstable</literal> removed.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--remove</option> <replaceable>name</replaceable></term>
|
||||
|
||||
<listitem><para>Removes the channel named
|
||||
<replaceable>name</replaceable> from the list of subscribed
|
||||
channels.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--list</option></term>
|
||||
|
||||
<listitem><para>Prints the names and URLs of all subscribed
|
||||
channels on standard output.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry><term><option>--update</option> [<replaceable>names</replaceable>…]</term>
|
||||
|
||||
<listitem><para>Downloads the Nix expressions of all subscribed
|
||||
channels (or only those included in
|
||||
<replaceable>names</replaceable> if specified), makes them the
|
||||
default for <command>nix-env</command> operations (by symlinking
|
||||
them from the directory <filename>~/.nix-defexpr</filename>), and
|
||||
performs a <command>nix-pull</command> on the manifests of all
|
||||
channels to make pre-built binaries available.</para></listitem>
|
||||
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Note that <option>--add</option> does not automatically perform
|
||||
an update.</para>
|
||||
|
||||
<para>The list of subscribed channels is stored in
|
||||
<filename>~/.nix-channels</filename>.</para>
|
||||
|
||||
<para>A channel consists of two elements: a bzipped Tar archive
|
||||
containing the Nix expressions, and a manifest created by
|
||||
<command>nix-push</command>. These must be stored under
|
||||
<literal><replaceable>url</replaceable>/nixexprs.tar.bz2</literal> and
|
||||
<literal><replaceable>url</replaceable>/MANIFEST</literal>,
|
||||
respectively.</para>
|
||||
|
||||
</refsection>
|
||||
|
||||
<refsection><title>Examples</title>
|
||||
|
||||
<para>To subscribe to the Nixpkgs channel and install the GNU Hello package:</para>
|
||||
|
||||
<screen>
|
||||
$ nix-channel --add http://nixos.org/channels/nixpkgs-unstable
|
||||
$ nix-channel --update
|
||||
$ nix-env -iA nixpkgs.hello</screen>
|
||||
|
||||
</refsection>
|
||||
|
||||
</refentry>
|
||||
@@ -1,591 +0,0 @@
|
||||
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xml:id='chap-package-management'>
|
||||
|
||||
<title>Package Management</title>
|
||||
|
||||
|
||||
<para>This chapter discusses how to do package management with Nix,
|
||||
i.e., how to obtain, install, upgrade, and erase packages. This is
|
||||
the “user’s” perspective of the Nix system — people
|
||||
who want to <emphasis>create</emphasis> packages should consult
|
||||
<xref linkend='chap-writing-nix-expressions' />.</para>
|
||||
|
||||
|
||||
<section><title>Basic package management</title>
|
||||
|
||||
<para>The main command for package management is <link
|
||||
linkend="sec-nix-env"><command>nix-env</command></link>. You can use
|
||||
it to install, upgrade, and erase packages, and to query what
|
||||
packages are installed or are available for installation.</para>
|
||||
|
||||
<para>In Nix, different users can have different “views”
|
||||
on the set of installed applications. That is, there might be lots of
|
||||
applications present on the system (possibly in many different
|
||||
versions), but users can have a specific selection of those active —
|
||||
where “active” just means that it appears in a directory
|
||||
in the user’s <envar>PATH</envar>. Such a view on the set of
|
||||
installed applications is called a <emphasis>user
|
||||
environment</emphasis>, which is just a directory tree consisting of
|
||||
symlinks to the files of the active applications. </para>
|
||||
|
||||
<para>Components are installed from a set of <emphasis>Nix
|
||||
expressions</emphasis> that tell Nix how to build those packages,
|
||||
including, if necessary, their dependencies. There is a collection of
|
||||
Nix expressions called the Nix Package collection that contains
|
||||
packages ranging from basic development stuff such as GCC and Glibc,
|
||||
to end-user applications like Mozilla Firefox. (Nix is however not
|
||||
tied to the Nix Package collection; you could write your own Nix
|
||||
expressions based on it, or completely new ones.) You can download
|
||||
the latest version from <link
|
||||
xlink:href='http://nixos.org/nixpkgs/download.html' />.</para>
|
||||
|
||||
<para>Assuming that you have downloaded and unpacked a release of Nix
|
||||
Packages, you can view the set of available packages in the release:
|
||||
|
||||
<screen>
|
||||
$ nix-env -qaf nixpkgs-<replaceable>version</replaceable> '*'
|
||||
ant-blackdown-1.4.2
|
||||
aterm-2.2
|
||||
bash-3.0
|
||||
binutils-2.15
|
||||
bison-1.875d
|
||||
blackdown-1.4.2
|
||||
bzip2-1.0.2
|
||||
...</screen>
|
||||
|
||||
where <literal>nixpkgs-<replaceable>version</replaceable></literal> is
|
||||
where you’ve unpacked the release. The flag <option>-q</option>
|
||||
specifies a query operation; <option>-a</option> means that you want
|
||||
to show the “available” (i.e., installable) packages, as opposed to
|
||||
the installed packages; and <option>-f</option>
|
||||
<filename>nixpkgs-<replaceable>version</replaceable></filename>
|
||||
specifies the source of the packages. The argument
|
||||
<literal>'*'</literal> shows all installable packages. (The quotes are
|
||||
necessary to prevent shell expansion.) You can also select specific
|
||||
packages by name:
|
||||
|
||||
<screen>
|
||||
$ nix-env -qaf nixpkgs-<replaceable>version</replaceable> gcc
|
||||
gcc-3.4.6
|
||||
gcc-4.0.3
|
||||
gcc-4.1.1</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>It is also possible to see the <emphasis>status</emphasis> of
|
||||
available packages, i.e., whether they are installed into the user
|
||||
environment and/or present in the system:
|
||||
|
||||
<screen>
|
||||
$ nix-env -qasf nixpkgs-<replaceable>version</replaceable> '*'
|
||||
...
|
||||
-PS bash-3.0
|
||||
--S binutils-2.15
|
||||
IPS bison-1.875d
|
||||
...</screen>
|
||||
|
||||
The first character (<literal>I</literal>) indicates whether the
|
||||
package is installed in your current user environment. The second
|
||||
(<literal>P</literal>) indicates whether it is present on your system
|
||||
(in which case installing it into your user environment would be a
|
||||
very quick operation). The last one (<literal>S</literal>) indicates
|
||||
whether there is a so-called <emphasis>substitute</emphasis> for the
|
||||
package, which is Nix’s mechanism for doing binary deployment. It
|
||||
just means that Nix knows that it can fetch a pre-built package from
|
||||
somewhere (typically a network server) instead of building it
|
||||
locally.</para>
|
||||
|
||||
<para>So now that we have a set of Nix expressions we can build the
|
||||
packages contained in them. This is done using <literal>nix-env
|
||||
-i</literal>. For instance,
|
||||
|
||||
<screen>
|
||||
$ nix-env -f nixpkgs-<replaceable>version</replaceable> -i subversion</screen>
|
||||
|
||||
will install the package called <literal>subversion</literal> (which
|
||||
is, of course, the <link
|
||||
xlink:href='http://subversion.tigris.org/'>Subversion version
|
||||
management system</link>).</para>
|
||||
|
||||
<para>When you do this for the first time, Nix will start building
|
||||
Subversion and all its dependencies. This will take quite a while —
|
||||
typically an hour or two on modern machines. Fortunately, there is a
|
||||
faster way (so do a Ctrl-C on that install operation!): you just need
|
||||
to tell Nix that pre-built binaries of all those packages are
|
||||
available somewhere. This is done using the
|
||||
<command>nix-pull</command> command, which must be supplied with a URL
|
||||
containing a <emphasis>manifest</emphasis> describing what binaries
|
||||
are available. This URL should correspond to the Nix Packages release
|
||||
that you’re using. For instance, if you obtained a release from <link
|
||||
xlink:href='http://nixos.org/releases/nixpkgs/nixpkgs-0.12pre11712-4lrp7j8x'
|
||||
/>, then you should do:
|
||||
|
||||
<screen>
|
||||
$ nix-pull http://nixos.org/releases/nixpkgs/nixpkgs-0.12pre11712-4lrp7j8x/MANIFEST</screen>
|
||||
|
||||
If you then issue the installation command, it should start
|
||||
downloading binaries from <systemitem
|
||||
class='fqdomainname'>nixos.org</systemitem>, instead of building
|
||||
them from source. This might still take a while since all
|
||||
dependencies must be downloaded, but on a reasonably fast connection
|
||||
such as an DSL line it’s on the order of a few minutes.</para>
|
||||
|
||||
<para>Naturally, packages can also be uninstalled:
|
||||
|
||||
<screen>
|
||||
$ nix-env -e subversion</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Upgrading to a new version is just as easy. If you have a new
|
||||
release of Nix Packages, you can do:
|
||||
|
||||
<screen>
|
||||
$ nix-env -f nixpkgs-<replaceable>version</replaceable> -u subversion</screen>
|
||||
|
||||
This will <emphasis>only</emphasis> upgrade Subversion if there is a
|
||||
“newer” version in the new set of Nix expressions, as
|
||||
defined by some pretty arbitrary rules regarding ordering of version
|
||||
numbers (which generally do what you’d expect of them). To just
|
||||
unconditionally replace Subversion with whatever version is in the Nix
|
||||
expressions, use <parameter>-i</parameter> instead of
|
||||
<parameter>-u</parameter>; <parameter>-i</parameter> will remove
|
||||
whatever version is already installed.</para>
|
||||
|
||||
<para>You can also upgrade all packages for which there are newer
|
||||
versions:
|
||||
|
||||
<screen>
|
||||
$ nix-env -f nixpkgs-<replaceable>version</replaceable> -u '*'</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>Sometimes it’s useful to be able to ask what
|
||||
<command>nix-env</command> would do, without actually doing it. For
|
||||
instance, to find out what packages would be upgraded by
|
||||
<literal>nix-env -u '*'</literal>, you can do
|
||||
|
||||
<screen>
|
||||
$ nix-env ... -u '*' --dry-run
|
||||
(dry run; not doing anything)
|
||||
upgrading `libxslt-1.1.0' to `libxslt-1.1.10'
|
||||
upgrading `graphviz-1.10' to `graphviz-1.12'
|
||||
upgrading `coreutils-5.0' to `coreutils-5.2.1'</screen>
|
||||
|
||||
</para>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<section xml:id="sec-profiles"><title>Profiles</title>
|
||||
|
||||
<para>Profiles and user environments are Nix’s mechanism for
|
||||
implementing the ability to allow different users to have different
|
||||
configurations, and to do atomic upgrades and rollbacks. To
|
||||
understand how they work, it’s useful to know a bit about how Nix
|
||||
works. In Nix, packages are stored in unique locations in the
|
||||
<emphasis>Nix store</emphasis> (typically,
|
||||
<filename>/nix/store</filename>). For instance, a particular version
|
||||
of the Subversion package might be stored in a directory
|
||||
<filename>/nix/store/dpmvp969yhdqs7lm2r1a3gng7pyq6vy4-subversion-1.1.3/</filename>,
|
||||
while another version might be stored in
|
||||
<filename>/nix/store/5mq2jcn36ldlmh93yj1n8s9c95pj7c5s-subversion-1.1.2</filename>.
|
||||
The long strings prefixed to the directory names are cryptographic
|
||||
hashes<footnote><para>160-bit truncations of SHA-256 hashes encoded in
|
||||
a base-32 notation, to be precise.</para></footnote> of
|
||||
<emphasis>all</emphasis> inputs involved in building the package —
|
||||
sources, dependencies, compiler flags, and so on. So if two
|
||||
packages differ in any way, they end up in different locations in
|
||||
the file system, so they don’t interfere with each other. <xref
|
||||
linkend='fig-user-environments' /> shows a part of a typical Nix
|
||||
store.</para>
|
||||
|
||||
<figure xml:id='fig-user-environments'><title>User environments</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref='figures/user-environments.png' format='PNG' />
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
|
||||
<para>Of course, you wouldn’t want to type
|
||||
|
||||
<screen>
|
||||
$ /nix/store/dpmvp969yhdq...-subversion-1.1.3/bin/svn</screen>
|
||||
|
||||
every time you want to run Subversion. Of course we could set up the
|
||||
<envar>PATH</envar> environment variable to include the
|
||||
<filename>bin</filename> directory of every package we want to use,
|
||||
but this is not very convenient since changing <envar>PATH</envar>
|
||||
doesn’t take effect for already existing processes. The solution Nix
|
||||
uses is to create directory trees of symlinks to
|
||||
<emphasis>activated</emphasis> packages. These are called
|
||||
<emphasis>user environments</emphasis> and they are packages
|
||||
themselves (though automatically generated by
|
||||
<command>nix-env</command>), so they too reside in the Nix store. For
|
||||
instance, in <xref linkend='fig-user-environments' /> the user
|
||||
environment <filename>/nix/store/5mq2jcn36ldl...-user-env</filename>
|
||||
contains a symlink to just Subversion 1.1.2 (arrows in the figure
|
||||
indicate symlinks). This would be what we would obtain if we had done
|
||||
|
||||
<screen>
|
||||
$ nix-env -i subversion</screen>
|
||||
|
||||
on a set of Nix expressions that contained Subversion 1.1.2.</para>
|
||||
|
||||
<para>This doesn’t in itself solve the problem, of course; you
|
||||
wouldn’t want to type
|
||||
<filename>/nix/store/0c1p5z4kda11...-user-env/bin/svn</filename>
|
||||
either. That’s why there are symlinks outside of the store that point
|
||||
to the user environments in the store; for instance, the symlinks
|
||||
<filename>default-42-link</filename> and
|
||||
<filename>default-43-link</filename> in the example. These are called
|
||||
<emphasis>generations</emphasis> since every time you perform a
|
||||
<command>nix-env</command> operation, a new user environment is
|
||||
generated based on the current one. For instance, generation 43 was
|
||||
created from generation 42 when we did
|
||||
|
||||
<screen>
|
||||
$ nix-env -i subversion mozilla</screen>
|
||||
|
||||
on a set of Nix expressions that contained Mozilla and a new version
|
||||
of Subversion.</para>
|
||||
|
||||
<para>Generations are grouped together into
|
||||
<emphasis>profiles</emphasis> so that different users don’t interfere
|
||||
with each other if they don’t want to. For example:
|
||||
|
||||
<screen>
|
||||
$ ls -l /nix/var/nix/profiles/
|
||||
...
|
||||
lrwxrwxrwx 1 eelco ... default-42-link -> /nix/store/0c1p5z4kda11...-user-env
|
||||
lrwxrwxrwx 1 eelco ... default-43-link -> /nix/store/3aw2pdyx2jfc...-user-env
|
||||
lrwxrwxrwx 1 eelco ... default -> default-43-link</screen>
|
||||
|
||||
This shows a profile called <filename>default</filename>. The file
|
||||
<filename>default</filename> itself is actually a symlink that points
|
||||
to the current generation. When we do a <command>nix-env</command>
|
||||
operation, a new user environment and generation link are created
|
||||
based on the current one, and finally the <filename>default</filename>
|
||||
symlink is made to point at the new generation. This last step is
|
||||
atomic on Unix, which explains how we can do atomic upgrades. (Note
|
||||
that the building/installing of new packages doesn’t interfere in
|
||||
any way with old packages, since they are stored in different
|
||||
locations in the Nix store.)</para>
|
||||
|
||||
<para>If you find that you want to undo a <command>nix-env</command>
|
||||
operation, you can just do
|
||||
|
||||
<screen>
|
||||
$ nix-env --rollback</screen>
|
||||
|
||||
which will just make the current generation link point at the previous
|
||||
link. E.g., <filename>default</filename> would be made to point at
|
||||
<filename>default-42-link</filename>. You can also switch to a
|
||||
specific generation:
|
||||
|
||||
<screen>
|
||||
$ nix-env --switch-generation 43</screen>
|
||||
|
||||
which in this example would roll forward to generation 43 again. You
|
||||
can also see all available generations:
|
||||
|
||||
<screen>
|
||||
$ nix-env --list-generations</screen></para>
|
||||
|
||||
<para>Actually, there is another level of indirection not shown in the
|
||||
figure above. You generally wouldn’t have
|
||||
<filename>/nix/var/nix/profiles/<replaceable>some-profile</replaceable>/bin</filename>
|
||||
in your <envar>PATH</envar>. Rather, there is a symlink
|
||||
<filename>~/.nix-profile</filename> that points to your current
|
||||
profile. This means that you should put
|
||||
<filename>~/.nix-profile/bin</filename> in your <envar>PATH</envar>
|
||||
(and indeed, that’s what the initialisation script
|
||||
<filename>/nix/etc/profile.d/nix.sh</filename> does). This makes it
|
||||
easier to switch to a different profile. You can do that using the
|
||||
command <command>nix-env --switch-profile</command>:
|
||||
|
||||
<screen>
|
||||
$ nix-env --switch-profile /nix/var/nix/profiles/my-profile
|
||||
|
||||
$ nix-env --switch-profile /nix/var/nix/profiles/default</screen>
|
||||
|
||||
These commands switch to the <filename>my-profile</filename> and
|
||||
default profile, respectively. If the profile doesn’t exist, it will
|
||||
be created automatically. You should be careful about storing a
|
||||
profile in another location than the <filename>profiles</filename>
|
||||
directory, since otherwise it might not be used as a root of the
|
||||
garbage collector (see <xref linkend='sec-garbage-collection'
|
||||
/>).</para>
|
||||
|
||||
<para>All <command>nix-env</command> operations work on the profile
|
||||
pointed to by <command>~/.nix-profile</command>, but you can override
|
||||
this using the <option>--profile</option> option (abbreviation
|
||||
<option>-p</option>):
|
||||
|
||||
<screen>
|
||||
$ nix-env -p /nix/var/nix/profiles/other-profile -i subversion</screen>
|
||||
|
||||
This will <emphasis>not</emphasis> change the
|
||||
<command>~/.nix-profile</command> symlink.</para>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<section xml:id='sec-garbage-collection'><title>Garbage collection</title>
|
||||
|
||||
<para><command>nix-env</command> operations such as upgrades
|
||||
(<option>-u</option>) and uninstall (<option>-e</option>) never
|
||||
actually delete packages from the system. All they do (as shown
|
||||
above) is to create a new user environment that no longer contains
|
||||
symlinks to the “deleted” packages.</para>
|
||||
|
||||
<para>Of course, since disk space is not infinite, unused packages
|
||||
should be removed at some point. You can do this by running the Nix
|
||||
garbage collector. It will remove from the Nix store any package
|
||||
not used (directly or indirectly) by any generation of any
|
||||
profile.</para>
|
||||
|
||||
<para>Note however that as long as old generations reference a
|
||||
package, it will not be deleted. After all, we wouldn’t be able to
|
||||
do a rollback otherwise. So in order for garbage collection to be
|
||||
effective, you should also delete (some) old generations. Of course,
|
||||
this should only be done if you are certain that you will not need to
|
||||
roll back.</para>
|
||||
|
||||
<para>To delete all old (non-current) generations of your current
|
||||
profile:
|
||||
|
||||
<screen>
|
||||
$ nix-env --delete-generations old</screen>
|
||||
|
||||
Instead of <literal>old</literal> you can also specify a list of
|
||||
generations, e.g.,
|
||||
|
||||
<screen>
|
||||
$ nix-env --delete-generations 10 11 14</screen>
|
||||
|
||||
</para>
|
||||
|
||||
<para>After removing appropriate old generations you can run the
|
||||
garbage collector as follows:
|
||||
|
||||
<screen>
|
||||
$ nix-store --gc</screen>
|
||||
|
||||
If you are feeling uncertain, you can also first view what files would
|
||||
be deleted:
|
||||
|
||||
<screen>
|
||||
$ nix-store --gc --print-dead</screen>
|
||||
|
||||
Likewise, the option <option>--print-live</option> will show the paths
|
||||
that <emphasis>won’t</emphasis> be deleted.</para>
|
||||
|
||||
<para>There is also a convenient little utility
|
||||
<command>nix-collect-garbage</command>, which when invoked with the
|
||||
<option>-d</option> (<option>--delete-old</option>) switch deletes all
|
||||
old generations of all profiles in
|
||||
<filename>/nix/var/nix/profiles</filename>. So
|
||||
|
||||
<screen>
|
||||
$ nix-collect-garbage -d</screen>
|
||||
|
||||
is a quick and easy way to clean up your system.</para>
|
||||
|
||||
|
||||
|
||||
|
||||
<section xml:id="ssec-gc-roots"><title>Garbage collector roots</title>
|
||||
|
||||
<para>The roots of the garbage collector are all store paths to which
|
||||
there are symlinks in the directory
|
||||
<filename><replaceable>prefix</replaceable>/nix/var/nix/gcroots</filename>.
|
||||
For instance, the following command makes the path
|
||||
<filename>/nix/store/d718ef...-foo</filename> a root of the collector:
|
||||
|
||||
<screen>
|
||||
$ ln -s /nix/store/d718ef...-foo /nix/var/nix/gcroots/bar</screen>
|
||||
|
||||
That is, after this command, the garbage collector will not remove
|
||||
<filename>/nix/store/d718ef...-foo</filename> or any of its
|
||||
dependencies.</para>
|
||||
|
||||
<para>Subdirectories of
|
||||
<filename><replaceable>prefix</replaceable>/nix/var/nix/gcroots</filename>
|
||||
are also searched for symlinks. Symlinks to non-store paths are
|
||||
followed and searched for roots, but symlinks to non-store paths
|
||||
<emphasis>inside</emphasis> the paths reached in that way are not
|
||||
followed to prevent infinite recursion.</para>
|
||||
|
||||
</section>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<section xml:id="sec-channels"><title>Channels</title>
|
||||
|
||||
<para>If you want to stay up to date with a set of packages, it’s not
|
||||
very convenient to manually download the latest set of Nix expressions
|
||||
for those packages, use <command>nix-pull</command> to register
|
||||
pre-built binaries (if available), and upgrade using
|
||||
<command>nix-env</command>. Fortunately, there’s a better way:
|
||||
<emphasis>Nix channels</emphasis>.</para>
|
||||
|
||||
<para>A Nix channel is just a URL that points to a place that contains
|
||||
a set of Nix expressions and a manifest. Using the command <link
|
||||
linkend="sec-nix-channel"><command>nix-channel</command></link> you
|
||||
can automatically stay up to date with whatever is available at that
|
||||
URL.</para>
|
||||
|
||||
<para>You can “subscribe” to a channel using
|
||||
<command>nix-channel --add</command>, e.g.,
|
||||
|
||||
<screen>
|
||||
$ nix-channel --add http://nixos.org/channels/nixpkgs-unstable</screen>
|
||||
|
||||
subscribes you to a channel that always contains that latest version
|
||||
of the Nix Packages collection. (Instead of
|
||||
<literal>nixpkgs-unstable</literal> you could also subscribe to
|
||||
<literal>nixpkgs-stable</literal>, which should have a higher level of
|
||||
stability, but right now is just outdated.) Subscribing really just
|
||||
means that the URL is added to the file
|
||||
<filename>~/.nix-channels</filename>. Right now there is no command
|
||||
to “unsubscribe”; you should just edit that file manually
|
||||
and delete the offending URL.</para>
|
||||
|
||||
<para>To obtain the latest Nix expressions available in a channel, do
|
||||
|
||||
<screen>
|
||||
$ nix-channel --update</screen>
|
||||
|
||||
This downloads the Nix expressions in every channel (downloaded from
|
||||
<literal><replaceable>url</replaceable>/nixexprs.tar.bz2</literal>)
|
||||
and registers any available pre-built binaries in every channel
|
||||
(by <command>nix-pull</command>ing
|
||||
<literal><replaceable>url</replaceable>/MANIFEST</literal>). It also
|
||||
makes the union of each channel’s Nix expressions the default for
|
||||
<command>nix-env</command> operations. Consequently, you can then say
|
||||
|
||||
<screen>
|
||||
$ nix-env -u '*'</screen>
|
||||
|
||||
to upgrade all packages in your profile to the latest versions
|
||||
available in the subscribed channels.</para>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<section xml:id="sec-one-click"><title>One-click installs</title>
|
||||
|
||||
<para>Often, when you want to install a specific package (e.g., from
|
||||
the <link
|
||||
xlink:href="http://nixos.org/nixpkgs/">Nix
|
||||
Packages collection</link>), subscribing to a channel is a bit
|
||||
cumbersome. And channels don’t help you at all if you want to install
|
||||
an older version of a package than the one provided by the current
|
||||
contents of the channel, or a package that has been removed from the
|
||||
channel. That’s when <emphasis>one-click installs</emphasis> come in
|
||||
handy: you can just go to the web page that contains the package,
|
||||
click on it, and it will be installed with all the necessary
|
||||
dependencies.</para>
|
||||
|
||||
<para>For instance, you can go to <link
|
||||
xlink:href="http://hydra.nixos.org/jobset/nixpkgs/trunk/channel/latest"
|
||||
/> and click on any link for the individual packages for your
|
||||
platform. The first time you do this, your browser will ask what to
|
||||
do with <literal>application/nix-package</literal> files. You should
|
||||
open them with <filename>/nix/bin/nix-install-package</filename>.
|
||||
This will open a window that asks you to confirm that you want to
|
||||
install the package. When you answer <literal>Y</literal>, the
|
||||
package and all its dependencies will be installed. This is a binary
|
||||
deployment mechanism — you get packages pre-compiled for the selected
|
||||
platform type.</para>
|
||||
|
||||
<para>You can also install <literal>application/nix-package</literal>
|
||||
files from the command line directly. See <xref
|
||||
linkend='sec-nix-install-package' /> for details.</para>
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
<section xml:id="sec-sharing-packages"><title>Sharing packages between machines</title>
|
||||
|
||||
<para>Sometimes you want to copy a package from one machine to
|
||||
another. Or, you want to install some packages and you know that
|
||||
another machine already has some or all of those packages or their
|
||||
dependencies. In that case there are mechanisms to quickly copy
|
||||
packages between machines.</para>
|
||||
|
||||
<para>The command <command
|
||||
linkend="sec-nix-copy-closure">nix-copy-closure</command> copies a Nix
|
||||
store path along with all its dependencies to or from another machine
|
||||
via the SSH protocol. It doesn’t copy store paths that are already
|
||||
present on the target machine. For example, the following command
|
||||
copies Firefox with all its dependencies:
|
||||
|
||||
<screen>
|
||||
$ nix-copy-closure --to alice@itchy.example.org $(type -p firefox)</screen>
|
||||
|
||||
See <xref linkend='sec-nix-copy-closure' /> for details.</para>
|
||||
|
||||
<para>With <command linkend='refsec-nix-store-export'>nix-store
|
||||
--export</command> and <command
|
||||
linkend='refsec-nix-store-import'>nix-store --import</command> you can
|
||||
write the closure of a store path (that is, the path and all its
|
||||
dependencies) to a file, and then unpack that file into another Nix
|
||||
store. For example,
|
||||
|
||||
<screen>
|
||||
$ nix-store --export $(nix-store -qR $(type -p firefox)) > firefox.closure</screen>
|
||||
|
||||
writes the closure of Firefox to a file. You can then copy this file
|
||||
to another machine and install the closure:
|
||||
|
||||
<screen>
|
||||
$ nix-store --import < firefox.closure</screen>
|
||||
|
||||
Any store paths in the closure that are already present in the target
|
||||
store are ignored. It is also possible to pipe the export into
|
||||
another command, e.g. to copy and install a closure directly to/on
|
||||
another machine:
|
||||
|
||||
<screen>
|
||||
$ nix-store --export $(nix-store -qR $(type -p firefox)) | bzip2 | \
|
||||
ssh alice@itchy.example.org "bunzip2 | nix-store --import"</screen>
|
||||
|
||||
But note that <command>nix-copy-closure</command> is generally more
|
||||
efficient in this example because it only copies paths that are not
|
||||
already present in the target Nix store.</para>
|
||||
|
||||
<para>Finally, if you can mount the Nix store of a remote machine in
|
||||
your local filesystem, Nix can copy paths from the remote Nix store to
|
||||
the local Nix store <emphasis>on demand</emphasis>. For instance,
|
||||
suppose that you mount a remote machine containing a Nix store via
|
||||
<command
|
||||
xlink:href="http://fuse.sourceforge.net/sshfs.html">sshfs</command>:
|
||||
|
||||
<screen>
|
||||
$ sshfs alice@itchy.example.org:/ /mnt</screen>
|
||||
|
||||
You should then set the <envar>NIX_OTHER_STORES</envar> environment
|
||||
variable to tell Nix about this remote Nix store:
|
||||
|
||||
<screen>
|
||||
$ export NIX_OTHER_STORES=/mnt/nix</screen>
|
||||
|
||||
Then if you do any Nix operation, e.g.
|
||||
|
||||
<screen>
|
||||
$ nix-env -i firefox</screen>
|
||||
|
||||
and Nix has to build a path that it sees is already present in
|
||||
<filename>/mnt/nix</filename>, then it will just copy from there
|
||||
instead of building it from source.</para>
|
||||
|
||||
|
||||
</section>
|
||||
|
||||
|
||||
</chapter>
|
||||