Packaging/Tutorial: Difference between revisions
imported>Mic92 No edit summary |
imported>Tv m fix typo |
||
Line 8: | Line 8: | ||
<ol style="list-style-type: decimal;"> | <ol style="list-style-type: decimal;"> | ||
<li><p>Detect package building category. It may be something simple, that | <li><p>Detect package building category. It may be something simple, that requires <code>gcc</code> and <code>make</code> only, or it may be a python library, or it may be a python application, or it may be [https://nixos.org/nixpkgs/manual/#chap-language-support any other LANGUAGE library/application], or it may be Qt applications, or it may be a Gnome application, or it does uses Mono/wine under a hood, or it vendors it's dependencies, or it is closed source/binary redistributable, or it uses CMake/any other alternative build tool, or it actually is a compiler, ... There are lots of such build categories, and it often isn't reflected at hierarchy level in Nixpkgs source tree.</p></li> | ||
<li><p>Try <code>grep</code>ping for building category keywords in Nixpkgs source. Find some example packages, review them and copy one of them as a new expression for your package. Too bad if you didn't find anything, then you should read Nix Pills first and skim through several package expressions in Nixpkgs source to be able to write own one.</p></li> | <li><p>Try <code>grep</code>ping for building category keywords in Nixpkgs source. Find some example packages, review them and copy one of them as a new expression for your package. Too bad if you didn't find anything, then you should read Nix Pills first and skim through several package expressions in Nixpkgs source to be able to write own one.</p></li> | ||
<li><p>Build it without changes, just to test it builds</p></li> | <li><p>Build it without changes, just to test it builds</p></li> |
Revision as of 16:49, 31 August 2017
If you are a new Nix adept and want to package some new software, you will benefit from reading existing Nix package descriptions. The more you read, the faster you'll do your package. I've even based a "Generic Algorithm on Doing Packaging Using Existing Knowledge" on this fact.
NOTE1: If you have time, read Nix Pills first
NOTE2: If you have even more time, read Nix manual to get familiar with Nix syntax
NOTE3: If you definitely have lots of time, then read Nixpkgs manual
Detect package building category. It may be something simple, that requires
gcc
andmake
only, or it may be a python library, or it may be a python application, or it may be any other LANGUAGE library/application, or it may be Qt applications, or it may be a Gnome application, or it does uses Mono/wine under a hood, or it vendors it's dependencies, or it is closed source/binary redistributable, or it uses CMake/any other alternative build tool, or it actually is a compiler, ... There are lots of such build categories, and it often isn't reflected at hierarchy level in Nixpkgs source tree.Try
grep
ping for building category keywords in Nixpkgs source. Find some example packages, review them and copy one of them as a new expression for your package. Too bad if you didn't find anything, then you should read Nix Pills first and skim through several package expressions in Nixpkgs source to be able to write own one.Build it without changes, just to test it builds
Modify source URL and sha256. Don't forget about that sha256 stuff! What I do, I change last symbol of sha256, let the package fail, and then paste correct sha256 again into expression. There are also various prefetch techniques
Run
nix-shell
on this expression (for example:nix-shell '<nixpkgs>' -A hello
). Then run in order:$ unpackPhase $ cd DIR_AFTER_UNPACK $ patchPhase $ configurePhase $ buildPhase
(visit stdenv-phases chapter to learn more about phases)
You may need to run $ eval "$configurePhase"
sometimes if build expression overrides that phase.
It most likely will fail.
- Try to find failure category. It may be headers not found, library not found, executable not found, compiler not found, wrong build system, empty result, and many many more... But solutions to these problems are a bit more controllable:
buildInput
dependency missing
- source requires patching
- you should enter a subdir first
- you should specify correct build parameters
patchShebangs
should be run first
- ....
Don't hesitate to learn from other package manager expressions, like AUR.
Apply a fix, exit nix-shell and enter it again. Do steps 6-7 while there are problems.
After you got
buildPhase
to pass and produce correct binaries/libraries, time toinstallPhase
. There are two ways: either you do package developement under root and have write access to Nix store inside nix-shell, or you simply runnix-build
on you expression, so Nix will perform it'sinstallPhase
.
In first case, you can run
$ installPhase
directly and examine using tree $out
your package files. If something is missing or too many, fix the postInstallPhase
or preInstallPhase
or installPhase
in your expression.
At this point you should have something that is both buildable and packageable. It still may not be runnable. Run the binaries to find out hidden dependencies, or patches required, or wrapper required, or patchelf required, or ... In general, I use Google and search in Nixpkgs issue tracker related problems.
After all the modifications, package should be buildable, runnable and should be self-sufficient. You may add
meta
section, but it isn't strictly required if you don't plan to publish your result.