[Nix-dev] nixos principles

[Marc Weber]

Excerpts from Roderick Ford's message of Sat Sep 25 05:08:20 +0200 2010:
> Ok, thanks, good to know that there is a wiki page to explain how to do
> this.  My thought was that I had found something to help the NixOS
> development with, but now I see that this has been done.  So, the lingering
> question that needs clarification:

Hi Roderick,

I recommend you jumping in and get started. Some of your questions will
find answers soon :)

I find it hard to reply to your questions, because they seem to be fuzzy
which probably is because you don't know the system very well yet.
> It appears then that NixOS developers do not only wrapper (set up the config
> files for) the installation packages by setting build parameters, etc., but
> also integrate patching for "special cases" where the package would not
> install without some changes.
pactches are added
- for personal preference reasons (at least I have some in my private
  repos)
- for "newer gcc" reasons because they interpret the .c files
  differently. Eg adding some header files is very often enough
- for 'tell them about dependency" reasons - or "remove impurity" or 
  "patch access to /usr/bin/which" reasons. (Those are compile time
  issues)
- for "put the state somewhere else" reasons. Which means even if an app
  compiles this does not automatically mean it behaves correctly.
- many more reasons I don't know or I forgot about.

> Is this done at the NixOS package manager
> level (by Eelco only?) rather than the config files,
WHat do you mean by patching? Many build recipes also have documented
configuration options. Eg see php_configurable in all-packages.nix.

> location for changing/adding the new options like "virtualbox.enable" and
> the code that runs when it is encountered?
the virtualbox.enable belongs to the NixOS configuration system. I
recommend jumping in and reading some code - asking questions while
doing so. It can be seen as huge lazy chunk of code which feeds the
configuration result as input again - kind of function with fix point.

There is no general answer. The configuration system is modular. Eg
there is are system setting assembling the system PATH, defining the
startup kernel modules etc. There are other modules describing how to
setup apache. You can override (would you call this patching?) many
settings, eg when a job should start / stop.

> Are there any statistics on how many packages are "done", how many are
> "patched" and how many total packages are not completed yet?  I assume that
> there are also cases where packages which were "done" or "configured", and
> have become "broken" by changes in the package.  Has anyone created a pie
> chart, or such, that shows this sort of "progress towards
> comprehensiveness"?
If you think about how to define the charts you can create them assuming
that you know when a package breaks.

let's simplify nixpkgs for you: Imagine you have a function with some
input arguments called:
  - kernel
  - gcc
  - glibc
  - graphic card
  - python version
  - qt version
  - gkt/glib version
  - .. (and some more)
  - compiled by a cross compiler (?)
  - which target? i686, x86_64, ... ?
  - even the filesystem + kernel you're using can make a difference.

Now you want some fancy charts? Do you want to have one chart for each
kernel or do you want to generate the chart for one kernel only?

What about python 2.5 packages which can also be run with python 2.6 ?
(Well let's say almost all ?)

Same for ghc, nixpkgs supports different ghc versions.

So is a package broken if it only works with python 2.7 but no longer
with 2.6?

So its easy to generate some charts (in fact Hydra does so. It creates a
list of packages which build and which don't..) However it only
evaluates a well defined set of packages - not all.

If you think about total packages and completness? completeness compared
to what? debian ? ubuntu? Windows? sourceforge? github ? gitorious? gnu
packages ? scrpting language packages such as cpan, hackage, rubyforge,
.. ?

I want to say: Its impossible to generate charts - because its that hard
to define the total amount of packages you could package.

I recommend you starting with the wiki article:
http://wiki.nixos.org/wiki/Howto_find_a_package_in_NixOS
so that you can judge yourself whether most software you are using is
supported.

Marc Weber