Clone of https://github.com/NixOS/nixpkgs.git (to stress-test knotserver)
at release-19.03 546 lines 17 kB view raw
1<chapter xmlns="http://docbook.org/ns/docbook" 2 xmlns:xlink="http://www.w3.org/1999/xlink" 3 xml:id="chap-packageconfig"> 4 <title>Global configuration</title> 5 <para> 6 Nix comes with certain defaults about what packages can and cannot be 7 installed, based on a package's metadata. By default, Nix will prevent 8 installation if any of the following criteria are true: 9 </para> 10 <itemizedlist> 11 <listitem> 12 <para> 13 The package is thought to be broken, and has had its 14 <literal>meta.broken</literal> set to <literal>true</literal>. 15 </para> 16 </listitem> 17 <listitem> 18 <para> 19 The package isn't intended to run on the given system, as none of its 20 <literal>meta.platforms</literal> match the given system. 21 </para> 22 </listitem> 23 <listitem> 24 <para> 25 The package's <literal>meta.license</literal> is set to a license which is 26 considered to be unfree. 27 </para> 28 </listitem> 29 <listitem> 30 <para> 31 The package has known security vulnerabilities but has not or can not be 32 updated for some reason, and a list of issues has been entered in to the 33 package's <literal>meta.knownVulnerabilities</literal>. 34 </para> 35 </listitem> 36 </itemizedlist> 37 <para> 38 Note that all this is checked during evaluation already, and the check 39 includes any package that is evaluated. In particular, all build-time 40 dependencies are checked. <literal>nix-env -qa</literal> will (attempt to) 41 hide any packages that would be refused. 42 </para> 43 <para> 44 Each of these criteria can be altered in the nixpkgs configuration. 45 </para> 46 <para> 47 The nixpkgs configuration for a NixOS system is set in the 48 <literal>configuration.nix</literal>, as in the following example: 49<programlisting> 50{ 51 nixpkgs.config = { 52 allowUnfree = true; 53 }; 54} 55</programlisting> 56 However, this does not allow unfree software for individual users. Their 57 configurations are managed separately. 58 </para> 59 <para> 60 A user's of nixpkgs configuration is stored in a user-specific configuration 61 file located at <filename>~/.config/nixpkgs/config.nix</filename>. For 62 example: 63<programlisting> 64{ 65 allowUnfree = true; 66} 67</programlisting> 68 </para> 69 <para> 70 Note that we are not able to test or build unfree software on Hydra due to 71 policy. Most unfree licenses prohibit us from either executing or 72 distributing the software. 73 </para> 74 <section xml:id="sec-allow-broken"> 75 <title>Installing broken packages</title> 76 77 <para> 78 There are two ways to try compiling a package which has been marked as 79 broken. 80 </para> 81 82 <itemizedlist> 83 <listitem> 84 <para> 85 For allowing the build of a broken package once, you can use an 86 environment variable for a single invocation of the nix tools: 87<programlisting>$ export NIXPKGS_ALLOW_BROKEN=1</programlisting> 88 </para> 89 </listitem> 90 <listitem> 91 <para> 92 For permanently allowing broken packages to be built, you may add 93 <literal>allowBroken = true;</literal> to your user's configuration file, 94 like this: 95<programlisting> 96{ 97 allowBroken = true; 98} 99</programlisting> 100 </para> 101 </listitem> 102 </itemizedlist> 103 </section> 104 <section xml:id="sec-allow-unsupported-system"> 105 <title>Installing packages on unsupported systems</title> 106 107 <para> 108 There are also two ways to try compiling a package which has been marked as 109 unsuported for the given system. 110 </para> 111 112 <itemizedlist> 113 <listitem> 114 <para> 115 For allowing the build of a broken package once, you can use an 116 environment variable for a single invocation of the nix tools: 117<programlisting>$ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1</programlisting> 118 </para> 119 </listitem> 120 <listitem> 121 <para> 122 For permanently allowing broken packages to be built, you may add 123 <literal>allowUnsupportedSystem = true;</literal> to your user's 124 configuration file, like this: 125<programlisting> 126{ 127 allowUnsupportedSystem = true; 128} 129</programlisting> 130 </para> 131 </listitem> 132 </itemizedlist> 133 134 <para> 135 The difference between a package being unsupported on some system and 136 being broken is admittedly a bit fuzzy. If a program 137 <emphasis>ought</emphasis> to work on a certain platform, but doesn't, the 138 platform should be included in <literal>meta.platforms</literal>, but marked 139 as broken with e.g. <literal>meta.broken = 140 !hostPlatform.isWindows</literal>. Of course, this begs the question of what 141 "ought" means exactly. That is left to the package maintainer. 142 </para> 143 </section> 144 <section xml:id="sec-allow-unfree"> 145 <title>Installing unfree packages</title> 146 147 <para> 148 There are several ways to tweak how Nix handles a package which has been 149 marked as unfree. 150 </para> 151 152 <itemizedlist> 153 <listitem> 154 <para> 155 To temporarily allow all unfree packages, you can use an environment 156 variable for a single invocation of the nix tools: 157<programlisting>$ export NIXPKGS_ALLOW_UNFREE=1</programlisting> 158 </para> 159 </listitem> 160 <listitem> 161 <para> 162 It is possible to permanently allow individual unfree packages, while 163 still blocking unfree packages by default using the 164 <literal>allowUnfreePredicate</literal> configuration option in the user 165 configuration file. 166 </para> 167 <para> 168 This option is a function which accepts a package as a parameter, and 169 returns a boolean. The following example configuration accepts a package 170 and always returns false: 171<programlisting> 172{ 173 allowUnfreePredicate = (pkg: false); 174} 175</programlisting> 176 </para> 177 <para> 178 For a more useful example, try the following. This configuration 179 only allows unfree packages named flash player and visual studio 180 code: 181<programlisting> 182{ 183 allowUnfreePredicate = (pkg: builtins.elem 184 (builtins.parseDrvName pkg.name).name [ 185 "flashplayer" 186 "vscode" 187 ]); 188} 189</programlisting> 190 </para> 191 </listitem> 192 <listitem> 193 <para> 194 It is also possible to whitelist and blacklist licenses that are 195 specifically acceptable or not acceptable, using 196 <literal>whitelistedLicenses</literal> and 197 <literal>blacklistedLicenses</literal>, respectively. 198 </para> 199 <para> 200 The following example configuration whitelists the licenses 201 <literal>amd</literal> and <literal>wtfpl</literal>: 202<programlisting> 203{ 204 whitelistedLicenses = with stdenv.lib.licenses; [ amd wtfpl ]; 205} 206</programlisting> 207 </para> 208 <para> 209 The following example configuration blacklists the <literal>gpl3</literal> 210 and <literal>agpl3</literal> licenses: 211<programlisting> 212{ 213 blacklistedLicenses = with stdenv.lib.licenses; [ agpl3 gpl3 ]; 214} 215</programlisting> 216 </para> 217 </listitem> 218 </itemizedlist> 219 220 <para> 221 A complete list of licenses can be found in the file 222 <filename>lib/licenses.nix</filename> of the nixpkgs tree. 223 </para> 224 </section> 225 <section xml:id="sec-allow-insecure"> 226 <title>Installing insecure packages</title> 227 228 <para> 229 There are several ways to tweak how Nix handles a package which has been 230 marked as insecure. 231 </para> 232 233 <itemizedlist> 234 <listitem> 235 <para> 236 To temporarily allow all insecure packages, you can use an environment 237 variable for a single invocation of the nix tools: 238<programlisting>$ export NIXPKGS_ALLOW_INSECURE=1</programlisting> 239 </para> 240 </listitem> 241 <listitem> 242 <para> 243 It is possible to permanently allow individual insecure packages, while 244 still blocking other insecure packages by default using the 245 <literal>permittedInsecurePackages</literal> configuration option in the 246 user configuration file. 247 </para> 248 <para> 249 The following example configuration permits the installation of the 250 hypothetically insecure package <literal>hello</literal>, version 251 <literal>1.2.3</literal>: 252<programlisting> 253{ 254 permittedInsecurePackages = [ 255 "hello-1.2.3" 256 ]; 257} 258</programlisting> 259 </para> 260 </listitem> 261 <listitem> 262 <para> 263 It is also possible to create a custom policy around which insecure 264 packages to allow and deny, by overriding the 265 <literal>allowInsecurePredicate</literal> configuration option. 266 </para> 267 <para> 268 The <literal>allowInsecurePredicate</literal> option is a function which 269 accepts a package and returns a boolean, much like 270 <literal>allowUnfreePredicate</literal>. 271 </para> 272 <para> 273 The following configuration example only allows insecure packages with 274 very short names: 275<programlisting> 276{ 277 allowInsecurePredicate = (pkg: (builtins.stringLength (builtins.parseDrvName pkg.name).name) &lt;= 5); 278} 279</programlisting> 280 </para> 281 <para> 282 Note that <literal>permittedInsecurePackages</literal> is only checked if 283 <literal>allowInsecurePredicate</literal> is not specified. 284 </para> 285 </listitem> 286 </itemizedlist> 287 </section> 288<!--============================================================--> 289 <section xml:id="sec-modify-via-packageOverrides"> 290 <title>Modify packages via <literal>packageOverrides</literal></title> 291 292 <para> 293 You can define a function called <varname>packageOverrides</varname> in your 294 local <filename>~/.config/nixpkgs/config.nix</filename> to override Nix 295 packages. It must be a function that takes pkgs as an argument and returns a 296 modified set of packages. 297<programlisting> 298{ 299 packageOverrides = pkgs: rec { 300 foo = pkgs.foo.override { ... }; 301 }; 302} 303</programlisting> 304 </para> 305 </section> 306 <section xml:id="sec-declarative-package-management"> 307 <title>Declarative Package Management</title> 308 309 <section xml:id="sec-building-environment"> 310 <title>Build an environment</title> 311 312 <para> 313 Using <literal>packageOverrides</literal>, it is possible to manage 314 packages declaratively. This means that we can list all of our desired 315 packages within a declarative Nix expression. For example, to have 316 <literal>aspell</literal>, <literal>bc</literal>, 317 <literal>ffmpeg</literal>, <literal>coreutils</literal>, 318 <literal>gdb</literal>, <literal>nixUnstable</literal>, 319 <literal>emscripten</literal>, <literal>jq</literal>, 320 <literal>nox</literal>, and <literal>silver-searcher</literal>, we could 321 use the following in <filename>~/.config/nixpkgs/config.nix</filename>: 322 </para> 323 324<screen> 325{ 326 packageOverrides = pkgs: with pkgs; { 327 myPackages = pkgs.buildEnv { 328 name = "my-packages"; 329 paths = [ 330 aspell 331 bc 332 coreutils 333 gdb 334 ffmpeg 335 nixUnstable 336 emscripten 337 jq 338 nox 339 silver-searcher 340 ]; 341 }; 342 }; 343} 344</screen> 345 346 <para> 347 To install it into our environment, you can just run <literal>nix-env -iA 348 nixpkgs.myPackages</literal>. If you want to load the packages to be built 349 from a working copy of <literal>nixpkgs</literal> you just run 350 <literal>nix-env -f. -iA myPackages</literal>. To explore what's been 351 installed, just look through <filename>~/.nix-profile/</filename>. You can 352 see that a lot of stuff has been installed. Some of this stuff is useful 353 some of it isn't. Let's tell Nixpkgs to only link the stuff that we want: 354 </para> 355 356<screen> 357{ 358 packageOverrides = pkgs: with pkgs; { 359 myPackages = pkgs.buildEnv { 360 name = "my-packages"; 361 paths = [ 362 aspell 363 bc 364 coreutils 365 gdb 366 ffmpeg 367 nixUnstable 368 emscripten 369 jq 370 nox 371 silver-searcher 372 ]; 373 pathsToLink = [ "/share" "/bin" ]; 374 }; 375 }; 376} 377</screen> 378 379 <para> 380 <literal>pathsToLink</literal> tells Nixpkgs to only link the paths listed 381 which gets rid of the extra stuff in the profile. <filename>/bin</filename> 382 and <filename>/share</filename> are good defaults for a user environment, 383 getting rid of the clutter. If you are running on Nix on MacOS, you may 384 want to add another path as well, <filename>/Applications</filename>, that 385 makes GUI apps available. 386 </para> 387 </section> 388 389 <section xml:id="sec-getting-documentation"> 390 <title>Getting documentation</title> 391 392 <para> 393 After building that new environment, look through 394 <filename>~/.nix-profile</filename> to make sure everything is there that 395 we wanted. Discerning readers will note that some files are missing. Look 396 inside <filename>~/.nix-profile/share/man/man1/</filename> to verify this. 397 There are no man pages for any of the Nix tools! This is because some 398 packages like Nix have multiple outputs for things like documentation (see 399 section 4). Let's make Nix install those as well. 400 </para> 401 402<screen> 403{ 404 packageOverrides = pkgs: with pkgs; { 405 myPackages = pkgs.buildEnv { 406 name = "my-packages"; 407 paths = [ 408 aspell 409 bc 410 coreutils 411 ffmpeg 412 nixUnstable 413 emscripten 414 jq 415 nox 416 silver-searcher 417 ]; 418 pathsToLink = [ "/share/man" "/share/doc" "/bin" ]; 419 extraOutputsToInstall = [ "man" "doc" ]; 420 }; 421 }; 422} 423</screen> 424 425 <para> 426 This provides us with some useful documentation for using our packages. 427 However, if we actually want those manpages to be detected by man, we need 428 to set up our environment. This can also be managed within Nix expressions. 429 </para> 430 431<screen> 432{ 433 packageOverrides = pkgs: with pkgs; rec { 434 myProfile = writeText "my-profile" '' 435 export PATH=$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/sbin:/bin:/usr/sbin:/usr/bin 436 export MANPATH=$HOME/.nix-profile/share/man:/nix/var/nix/profiles/default/share/man:/usr/share/man 437 ''; 438 myPackages = pkgs.buildEnv { 439 name = "my-packages"; 440 paths = [ 441 (runCommand "profile" {} '' 442 mkdir -p $out/etc/profile.d 443 cp ${myProfile} $out/etc/profile.d/my-profile.sh 444 '') 445 aspell 446 bc 447 coreutils 448 ffmpeg 449 man 450 nixUnstable 451 emscripten 452 jq 453 nox 454 silver-searcher 455 ]; 456 pathsToLink = [ "/share/man" "/share/doc" "/bin" "/etc" ]; 457 extraOutputsToInstall = [ "man" "doc" ]; 458 }; 459 }; 460} 461</screen> 462 463 <para> 464 For this to work fully, you must also have this script sourced when you are 465 logged in. Try adding something like this to your 466 <filename>~/.profile</filename> file: 467 </para> 468 469<screen> 470#!/bin/sh 471if [ -d $HOME/.nix-profile/etc/profile.d ]; then 472 for i in $HOME/.nix-profile/etc/profile.d/*.sh; do 473 if [ -r $i ]; then 474 . $i 475 fi 476 done 477fi 478</screen> 479 480 <para> 481 Now just run <literal>source $HOME/.profile</literal> and you can starting 482 loading man pages from your environent. 483 </para> 484 </section> 485 486 <section xml:id="sec-gnu-info-setup"> 487 <title>GNU info setup</title> 488 489 <para> 490 Configuring GNU info is a little bit trickier than man pages. To work 491 correctly, info needs a database to be generated. This can be done with 492 some small modifications to our environment scripts. 493 </para> 494 495<screen> 496{ 497 packageOverrides = pkgs: with pkgs; rec { 498 myProfile = writeText "my-profile" '' 499 export PATH=$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/sbin:/bin:/usr/sbin:/usr/bin 500 export MANPATH=$HOME/.nix-profile/share/man:/nix/var/nix/profiles/default/share/man:/usr/share/man 501 export INFOPATH=$HOME/.nix-profile/share/info:/nix/var/nix/profiles/default/share/info:/usr/share/info 502 ''; 503 myPackages = pkgs.buildEnv { 504 name = "my-packages"; 505 paths = [ 506 (runCommand "profile" {} '' 507 mkdir -p $out/etc/profile.d 508 cp ${myProfile} $out/etc/profile.d/my-profile.sh 509 '') 510 aspell 511 bc 512 coreutils 513 ffmpeg 514 man 515 nixUnstable 516 emscripten 517 jq 518 nox 519 silver-searcher 520 texinfoInteractive 521 ]; 522 pathsToLink = [ "/share/man" "/share/doc" "/share/info" "/bin" "/etc" ]; 523 extraOutputsToInstall = [ "man" "doc" "info" ]; 524 postBuild = '' 525 if [ -x $out/bin/install-info -a -w $out/share/info ]; then 526 shopt -s nullglob 527 for i in $out/share/info/*.info $out/share/info/*.info.gz; do 528 $out/bin/install-info $i $out/share/info/dir 529 done 530 fi 531 ''; 532 }; 533 }; 534} 535</screen> 536 537 <para> 538 <literal>postBuild</literal> tells Nixpkgs to run a command after building 539 the environment. In this case, <literal>install-info</literal> adds the 540 installed info pages to <literal>dir</literal> which is GNU info's default 541 root node. Note that <literal>texinfoInteractive</literal> is added to the 542 environment to give the <literal>install-info</literal> command. 543 </para> 544 </section> 545 </section> 546</chapter>