[Nix-dev] Beginner question about external recipes

[Michael Raskin]

>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.

The reason we don't have it is quite simple.

We do convert external packages manually from time to time. I have seen
no rule that allows to find all implicit dependencies for any major 
distribution. People do miss dependencies from time to time. Who builds
libgnome with strictly no X packages except explicit dependencies 
installed? Hydra does (in chroot).

Additionally, installing in non-standard location sometimes requires
patching or fixing. Also, we need linker to remember our non-standard
paths to libraries.

So it would not work reliably anyway, and so noone volounteered to do
this.

>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.

Of course, name clashes are a trivial problem. 

>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. :)

We will have to maintain correspondence between Debian, ArchLinux, 
Gentoo, Fedora dependency names and our package names.. And it wouldn't
work too well.

I guess you could write 80% succesful converter of Debian packages into
Nix expressions, but that would be a lot of work.