[Nix-dev] Beginner question about external recipes

[Bryce L Nordgren]

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

More or less, I was thinking of Nix expressions to control some external
packaging mechanism (apt, makechrootpkg/pacman, rpmbuild/rpm) rather than
trying to convert the recipies themselves to Nix expressions. I've been
pondering this specific topic (and Nix in general) over the weekend.  I've
read some of the early papers on Nix, but I still may be struggling with
some of the concepts...particularly those related to functional
programming. Point out errors or insanity.

For context, my near term interest is to control an ArchLinux environment
for:

1] rollback capability
2] better closure determination for "point upgrades" (individual packages).
3] Automatic rebuilds of "customized" packages.

Note I'm not thinking to augment ArchLinux. I'm thinking to place instances
of ArchLinux under the control of something which understands closures and
their manipulation. This should generalize to other distributions as well.
Certain key assumptions need to be met, of course:

1] Analogies between the Nix deployment model and the external system need
to be made (recipe file, instantiation, derivation, retained dependencies).
2] The set of external recipe files should build within a controlled
environment which enforces package purity.
3] The external deployment scheme must produce the same result when
deploying the same closure of packages from scratch...even when this
closure is only a "subclosure" of all that is being deployed.
4] The external system must rely on its package management system (and the
metadata embodied therein) to deploy new systems (indicating a workable
level of purity).
5] A Nix managed system does not interfere with the managed external
system, and the union of the two filesystem images is the same whether the
host is NixOS or the host is the external system. (this is not strictly
necessary to manage a completely external system, but it does allow for a
hybrid filesystem hosting both Nixpkgs and external pkgs.)

Given these assumptions, it would seem to me to be possible to construct an
"external environment" for a packageset similar to how Nix currently
constructs user profiles...or how NixOS rebuilds itself from a
configuration file. Whether this environment is isolated as a VM image or
is maintained as a place to chroot to seems like an arbitrary distinction.
However, if it is a chroot, it makes it possible for Nix to assume control
of the external build process. Nix only has to understand the closure
relations, how to prep a build chroot, and how to actually execute a build
operation in that chroot. There is value in maintaining a "pure" NixOS host
filesystem mounted on "/". The merged filesystems would occupy a chroot
environment.

That takes care of objectives #1 and #3. Objective #2 falls out from
assumption #1: that a Nix analogy can be drawn between the artifacts and
metadata in an external package repository. If Nix understands the closure
expression which describes the current state of the system, and it
understands the closure relation for the current state of the repository,
it should be able to calculate an upgrade action which resolves any
dangling references (e.g., nix-env --upgrade --eq : attempt to recompile
any packages which depend on something which is getting overwritten).

For archlinux, I've got a set of analogies in mind (Assumption #1). I
believe assumption #2 is covered by makechrootpkg. I know that pacman is
used to cover #4...I'm assuming #3 without proof. Number 5 is supported by
what I've observed about Nix/NixOS so far (I think.)

I'm thinking there's at least the potential for wider use if this is pans
out. For instance, one shell could be chrooted into NixOS/ArchLinux and
another could be chrooted into NixOS/CentOS (actually, any other gnu/linux
distribution with a compatible kernel). NixOS could be the one distro in
existance with the capability to leverage packaged software from multiple
distros. You'll have more packages than you know what to do with, and an
enormous community maintaining those package descriptions to keep up with
the upstream.

Does this sound plausible to anyone else? Are there showstoppers?

Bryce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20111205/59f41fb4/attachment-0001.html