Nix vs. Linux Standard Base: Difference between revisions

(One intermediate revision by one other user not shown)

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.

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.

Line 39:

== 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]]

@@ 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.
-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.
@@ Line 39: / Line 39: @@
 == See also ==
-* [https://ostreedev.github.io/ostree/related-projects/#nixos--nix OSTree comparison to NixOS] &mdash; 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] &mdash; 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]]