Nix vs. Linux Standard Base: Difference between revisions

Line 35:

With Nix, any files inside the store (/nix/store, where all nix installed files end up; ~/.nix-profile is a symlink to a store path), are meant to be read-only. That is, nix expects those files only under her control, and it is a requirement to allow rollbacks and reproducibility. Of course the owner of the nix store can change files there, but then you cannot expect rollbacks or reproducibility. "nix-store --verify --check-contents" will tell you if there are files modified in the store (since the creation of each store path). Although modifying a file in the store seems like an easy quick fix, it should be regarded as bad as modifying the memory of a running process, because it has almost all the analogous downsides.

To modify the behavior of a Nix package, you typically have more than one option. The first approach you may consider is changing its runtime configuration: passing command line options, environment variables or configuration files that exist outside the package itself. Not modifying the definition of a ~~package has the benefit~~ of ~~being able~~ to ~~use the publicly available Hydra build cache.~~

For a discussion of methods to make (durable) changes to Nix packages, see [[Modifying a Package]]

~~If the software as packaged does not have the flexibility you need, you have various options.~~

~~Conceptually the most simple option is to duplicate the package definition in a local file where you~~ make ~~your~~ changes~~. You will be able~~ to ~~install and use it locally, while only having to learn the basics of~~ Nix ~~packaging.~~

~~If you expect your changes to be generally useful to others~~, ~~you may consider creating~~ a ~~pull request for [https://github.com/NixOS/nixpkgs nixpkgs on github~~]~~. This has the benefit that others can help maintaining the package and that a binary of your package will be available for you to download.~~

If upstreaming into the official NixPkgs is not an option, consider creating an overlay. This is slightly more involved at first, but is easier to maintain than a NixPkgs fork and, unlike a fork, it can be combined with other overlays. In an overlay, you can also choose not to redefine the package, but only override part of the arguments or derivation attributes. For example, you may only need to change one of the [https://nixos.org/nixpkgs/manual/#sec-stdenv-phases stdenv build phases].

[[Category:Discussion]]

@@ Line 35: / Line 35: @@
 With Nix, any files inside the store (/nix/store, where all nix installed files end up; ~/.nix-profile is a symlink to a store path), are meant to be read-only. That is, nix expects those files only under her control, and it is a requirement to allow rollbacks and reproducibility. Of course the owner of the nix store can change files there, but then you cannot expect rollbacks or reproducibility. "nix-store --verify --check-contents" will tell you if there are files modified in the store (since the creation of each store path). Although modifying a file in the store seems like an easy quick fix, it should be regarded as bad as modifying the memory of a running process, because it has almost all the analogous downsides.
-To modify the behavior of a Nix package, you typically have more than one option. The first approach you may consider is changing its runtime configuration: passing command line options, environment variables or configuration files that exist outside the package itself. Not modifying the definition of a package has the benefit of being able to use the publicly available Hydra build cache.
+For a discussion of methods to make (durable) changes to Nix packages, see [[Modifying a Package]]
-If the software as packaged does not have the flexibility you need, you have various options.
-Conceptually the most simple option is to duplicate the package definition in a local file where you make your changes. You will be able to install and use it locally, while only having to learn the basics of Nix packaging.
-If you expect your changes to be generally useful to others, you may consider creating a pull request for [https://github.com/NixOS/nixpkgs nixpkgs on github]. This has the benefit that others can help maintaining the package and that a binary of your package will be available for you to download.
-If upstreaming into the official NixPkgs is not an option, consider creating an overlay. This is slightly more involved at first, but is easier to maintain than a NixPkgs fork and, unlike a fork, it can be combined with other overlays. In an overlay, you can also choose not to redefine the package, but only override part of the arguments or derivation attributes. For example, you may only need to change one of the [https://nixos.org/nixpkgs/manual/#sec-stdenv-phases stdenv build phases].
 [[Category:Discussion]]