[Nix-dev] Beginner question about external recipes

[Bryce L Nordgren]

Hello.

I'm still wrapping my brain around Nix/Nixos/nixpkgs. I have a concept in
my head which is so basic it's probably been had before, so I was hoping
that someone could set me straight relatively easily.

I understand you have a stdenvNative environment, which essentially allows
you to use the nix deployment system on an external OS, assuming that
someone has written a nix expression for "package X". What I want to ask
is: Do you have the reverse?

In essense, do you have infrastructure in place which allows you to build
nix packages leveraging the vast collection of build recipes written for
other packaging systems? I envision this as essentially an adapter layer
which in which nix-build (or hydra) creates an expected build environment
(such as base-devel on Archlinux), deploys the package's declared
dependencies to this environment, executes the external build tools (which
understand the external recipes), deploys the external package to the nix
store, and results in a nix derivation with complete dependencies. (see
attached pdf illustration). I would not see this as a circumvention of the
nix philosophy, I see it as making the nix philosophy "multilingual" when
it comes to recipes.Please correct me if I am in error on this point.

This may introduce namespace issues for package names, particularly if
multiple collections of recipes are considered (e.g., archlinux and centos
and debian). It should not introduce "impurities"...at least in the way
stdenvNative does: everything is built with a nix-managed artifact (e.g., a
nix expression is written for the external build tools). Also: everything
is built from source by nix; no external binaries can be leveraged. These
"wrapped" packages will lack some functionality, of course (e.g.,
properties/attributes specific to the package). But it does make the
software available to a Nix system.

The build environment will need to look as the recipes expect it to look,
of course. However, this should be easy to fake! /bin should just contain
links to the contents of the bin directories in all of the
installed/available/required nix stores. Likewise for /lib, /usr/bin/
/var/lib/ and whatever else is out there. Clearly there will need to be a
difference between installing an "assimilated package" in the "external
build environment" and installing it on a live system.

Managing a small workgroup of linux stations, as well as a few
pseudoproduction servers gives me an appreciation of the nix deployment
model as well as the need for a hydra like build farm. I also have an
appreciation of the amount of work it takes to "stay current": maintaining
a set of recipes which track the many and varied upstreams. What I really
want is the best of both worlds, and of course I want it now. :)

I think I've nattered on enough. Please shoot this down mercilessly to
prevent me from mulling this over any longer. :)

Bryce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20111202/a2b05a59/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Nixwrapper.pdf
Type: application/pdf
Size: 24745 bytes
Desc: not available
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20111202/a2b05a59/attachment-0001.pdf