Nix vs. Linux Standard Base - Revision history

GangstersAreLame at 07:32, 5 May 2025

2025-05-05T07:32:45Z

← Older revision		Revision as of 07:32, 5 May 2025
Line 39:		Line 39:
	== See also ==		== See also ==

	* [https://ostreedev.github.io/ostree/related-projects/#nixos--nix ~~OSTree~~ comparison to NixOS] — ~~OSTree~~, a project to offer [https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard FHS]-compatible "stores", was in large part inspired by NixOS.		* [https://ostreedev.github.io/ostree/related-projects/#nixos--nix libostree comparison to NixOS] — libostree, a project to offer [https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard FHS]-compatible "stores", was in large part inspired by NixOS.

	[[Category:Pedias]]		[[Category:Pedias]]

Fidgetingbits: /* Build and install from Source */ formatting

2024-10-19T15:04:44Z

Build and install from Source: formatting

← Older revision		Revision as of 15:04, 19 October 2024
Line 17:		Line 17:
	With Nix, you can install the needed development tools into your profile (gcc-wrapper, gnumake), and the dependencies for the source you want to build (libpng, qt, ...). Once that done, set the environment variables (for gcc): <syntaxhighlight lang="bash" inline>CPATH=~/.nix-profile/include; LIBRARY_PATH=~/.nix-profile/lib; QTDIR=~/nix-profile</syntaxhighlight>... And then you should get your build running. In most LSB distributions, you proceed like the section above to build the program, and then run <code>make install</code> to get it into /usr/local, overwritting any files you had there.		With Nix, you can install the needed development tools into your profile (gcc-wrapper, gnumake), and the dependencies for the source you want to build (libpng, qt, ...). Once that done, set the environment variables (for gcc): <syntaxhighlight lang="bash" inline>CPATH=~/.nix-profile/include; LIBRARY_PATH=~/.nix-profile/lib; QTDIR=~/nix-profile</syntaxhighlight>... And then you should get your build running. In most LSB distributions, you proceed like the section above to build the program, and then run <code>make install</code> to get it into /usr/local, overwritting any files you had there.

	Using Nix, if you built your program like the section above, you may end up having /usr/local files depending on dynamic libraries only present in your profile. That situation may require a <code>LD_LIBRARY_PATH</code> variable, or your ld.so.conf pointing to your profile, but this situation can end in your programs not working if you remove those dependencies from your profile. This would be also a problem in your LSB distribution, if you remove uninstall packages required by programs you put manually in /usr/local.		Using Nix, if you built your program like the section above, you may end up having /usr/local files depending on dynamic libraries only present in your profile. That situation may require a <code>LD_LIBRARY_PATH</code> variable, or your ld.so.conf pointing to your profile, but this situation can end in your programs not working if you remove those dependencies from your profile. This would be also a problem in your LSB distribution, if you remove uninstall packages required by programs you put manually in <code>/usr/local</code>.

	Therefore, it is advisable to use Nix not only for acquiring dependencies, but also for managing the build of your package. In fact, creating an ad-hoc Nix package for the software is often easier, because the standard environment in NixPkgs automatically takes care of issues that could arise because of the differences between the Nix and LSB approaches. For example, a well packaged autotools-based project usually builds successfully after specifying its dependencies in Nix, whereas if you would install the dependencies and try to build it yourself, you will have a hard time.		Therefore, it is advisable to use Nix not only for acquiring dependencies, but also for managing the build of your package. In fact, creating an ad-hoc Nix package for the software is often easier, because the standard environment in NixPkgs automatically takes care of issues that could arise because of the differences between the Nix and LSB approaches. For example, a well packaged autotools-based project usually builds successfully after specifying its dependencies in Nix, whereas if you would install the dependencies and try to build it yourself, you will have a hard time.

Fidgetingbits: /* Package Installation */ tweak formatting

2024-10-19T15:03:35Z

Package Installation: tweak formatting

← Older revision		Revision as of 15:03, 19 October 2024
Line 7:		Line 7:
	With Nix, the files of a package go into a ''profile'' (as if it was a rootfs), and users can have as many profiles as they want.		With Nix, the files of a package go into a ''profile'' (as if it was a rootfs), and users can have as many profiles as they want.

	By default, the only part of the system made aware of the contents of the user profile is the PATH. The user PATH is set through bashrc to include `~/.nix-profile/bin`. So, by default, installing a Nix package means "having it in the PATH". A simple operation like <code>nix-env -i firefox</code> is meant to update the nix store, then generate a new profile in the store having all the programs ''installed'' plus the new one, and updating the symlink `~/.nix-profile`, so `~/.nix-profile/bin` will contain a symlink to the executable of firefox. Then a user can type <code>firefox</code> and have it running.		By default, the only part of the system made aware of the contents of the user profile is the <code>PATH</code> environment variable. The user <code>PATH</code> is set through bashrc to include <code>~/.nix-profile/bin</code>. So, by default, installing a Nix package means "having it in the PATH". A simple operation like <code>nix-env -i firefox</code> is meant to update the nix store, then generate a new profile in the store having all the programs ''installed'' plus the new one, and updating the symlink <code>~/.nix-profile</code>, so <code>~/.nix-profile/bin</code> will contain a symlink to the executable of firefox. Then a user can type <code>firefox</code> and have it running.

	If other kind of files are to be found by programs looking at the usual `<code>/{,usr}/{bin,etc,lib,sbin,...}</code>` locations, other variables may be of help. For example, gcc would welcome <code>CPATH</code> and <code>LIBRARY_PATH</code>. And the dynamic loader will welcome <code>LD_LIBRARY_PATH</code>.		If other kind of files are to be found by programs looking at the usual <code>/{,usr}/{bin,etc,lib,sbin,...}</code> locations, other variables may be of help. For example, gcc would welcome <code>CPATH</code> and <code>LIBRARY_PATH</code>. And the dynamic loader will welcome <code>LD_LIBRARY_PATH</code>.

	== Build and install from Source ==		== Build and install from Source ==

Sdht0: Partial copy edit

2024-04-08T04:55:57Z

Partial copy edit

← Older revision		Revision as of 04:55, 8 April 2024
Line 1:		Line 1:
	This article is a comparison between the ~~way~~ [[Nix]] ~~install packages to the filesystem hierarchy,~~ and the [https://en.wikipedia.org/wiki/Linux_Standard_Base Linux Standard Base] (LSB) standard ~~which~~ most conventional Linux distributions~~, package managers and installers~~ follow.		This article is a comparison between the [[Nix package manager]] and the [https://en.wikipedia.org/wiki/Linux_Standard_Base Linux Standard Base] (LSB) standard that the package managers of most conventional Linux distributions follow.

	== Package Installation ==		== Package Installation ==

	In most distributions, ~~asking for a~~ package ~~to be installed, means having all its files available in the root filesystem (~~<code>/{,usr}/{bin,etc,lib~~,sbin~~,...}</code>).		In most distributions, files of an installed package are stored under <code>/{,usr}/{bin,etc,lib,...}</code>.

	With Nix, the ~~installed~~ files of a package go into a ''profile'' (as if it was a rootfs), and ~~you~~ can have as many profiles as ~~you~~ want~~. There is the notion of each user having at least one profile, so `~/.nix-profile` points to the last version of the profile the user chose (last generation)~~.		With Nix, the files of a package go into a ''profile'' (as if it was a rootfs), and users can have as many profiles as they want.

	By default, the only part of the system made aware of the contents of the user profile is the PATH. The user PATH is set through bashrc to include `~/.nix-profile/bin`. So, by default, installing a Nix package means "having it in the PATH". A simple operation like <code>nix-env -i firefox</code> is meant to update the nix store, then generate a new profile in the store having all the programs ''installed'' plus the new one, and updating the symlink `~/.nix-profile`, so `~/.nix-profile/bin` will contain a symlink to the executable of firefox. Then a user can type <code>firefox</code> and have it running.		By default, the only part of the system made aware of the contents of the user profile is the PATH. The user PATH is set through bashrc to include `~/.nix-profile/bin`. So, by default, installing a Nix package means "having it in the PATH". A simple operation like <code>nix-env -i firefox</code> is meant to update the nix store, then generate a new profile in the store having all the programs ''installed'' plus the new one, and updating the symlink `~/.nix-profile`, so `~/.nix-profile/bin` will contain a symlink to the executable of firefox. Then a user can type <code>firefox</code> and have it running.

Sdht0: /* Modifying a Package */ Copy edit and shorten

2024-04-08T04:47:50Z

Modifying a Package: Copy edit and shorten

← Older revision		Revision as of 04:47, 8 April 2024
Line 31:		Line 31:

	== Modifying a Package ==		== Modifying a Package ==
	In LSB distributions, ~~after installing a package, you would go to~~ /usr~~/whatever and edit~~ the ~~files you want to change~~.		In LSB distributions, files installed under {{ic\|/usr}} can be edited by the user as needed.

	~~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~~.		Files in the Nix store ({{ic\|/nix/store}}) are meant to be read-only and changes are only done using the {{ic\|nix}} commands. {{ic\|nix-store --verify --check-contents}} can be used to ensure integrity of the store data.

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

	== See also ==		== See also ==

Sdht0: /* See also */ Update link

2024-04-08T04:38:55Z

imported>Nix: /* See also */ ref for FHS

2021-10-08T00:24:33Z

imported>Nix: add OSTree comparison

2021-10-08T00:23:23Z

add OSTree comparison

← Older revision		Revision as of 00:23, 8 October 2021
Line 36:		Line 36:

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

			== See also ==

			[https://ostree.readthedocs.io/en/stable/manual/related-projects/#nixos-nix OSTree comparison to NixOS] — OSTree, a project to offer FHS-compatible "stores" was in large part inspired by NixOS.

	[[Category:Pedias]]		[[Category:Pedias]]

imported>Nix: move to pedias category

2021-09-20T00:31:03Z

move to pedias category

← Older revision		Revision as of 00:31, 20 September 2021
Line 37:		Line 37:
	For a discussion of methods to make (durable) changes to Nix packages, see [[Modifying a Package]]		For a discussion of methods to make (durable) changes to Nix packages, see [[Modifying a Package]]

	[[Category:~~Discussion~~]]		[[Category:Pedias]]

imported>Roberth: Extract Modifying a Package into new page

2017-12-06T09:24:57Z

Extract Modifying a Package into new page

← Older revision		Revision as of 09:24, 6 December 2017
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.		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]]		[[Category:Discussion]]

← Older revision		Revision as of 04:38, 8 April 2024
Line 39:		Line 39:
	== See also ==		== See also ==

	[https://~~ostree~~.~~readthedocs~~.io/~~en/stable/manual~~/related-projects/#nixos-nix OSTree comparison to NixOS] — OSTree, a project to offer [https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard FHS]-compatible "stores" was in large part inspired by NixOS.		* [https://ostreedev.github.io/ostree/related-projects/#nixos--nix OSTree comparison to NixOS] — OSTree, a project to offer [https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard FHS]-compatible "stores", was in large part inspired by NixOS.

	[[Category:Pedias]]		[[Category:Pedias]]

← Older revision		Revision as of 00:24, 8 October 2021
Line 39:		Line 39:
	== See also ==		== See also ==

	[https://ostree.readthedocs.io/en/stable/manual/related-projects/#nixos-nix OSTree comparison to NixOS] — OSTree, a project to offer FHS-compatible "stores" was in large part inspired by NixOS.		[https://ostree.readthedocs.io/en/stable/manual/related-projects/#nixos-nix OSTree comparison to NixOS] — OSTree, a project to offer [https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard FHS]-compatible "stores" was in large part inspired by NixOS.

	[[Category:Pedias]]		[[Category:Pedias]]