[Nix-dev] Platform matching, accept/reject

[Tony White]

2009/8/12 Nathaniel Griswold <griswold at cs.wisc.edu>:
> Hi all,
>
> I'm interested in building with both pure and nonpure environments on
> the same machine using nix. The motivation for this is i'd like the
> expressiveness, ease of unprivileged deployment provided by nix to
> build not only pure tools, but also to build and cache several
> system-dependent libraries and tools that do /not/ depend on the nix
> store at all (but are also not system packages or necessarily built in
> VMs). It seems nix could be very helpful in expressing this controlled
> impurity and even scanning for unwanted store dependencies.
>
> As an example, maybe i want to build some software with an impure env
> that depends on system glibc and several system libraries for both
> debian 4 and debian 5. I decide that i don't want to build or nix-env
> install the impure debian5 derivations on debian4 and vice versa.
>
> Or maybe i want to build some packages with a pure glibc compiled
> against an older kernel for maximum compatibility across my different
> linux systems (and share them among all of them), but i i'd also like
> to build some binaries with newer kernel headers and only run those on
> systems running newer kernels (which i might statically define to be
> doing so).
>
> I'd also like to use this in a hetergenous, non-vm distributed build
> environment.
>
> It's trivial to pass different stdenvs into nixpkgs, or incorporate
> pieces of the environment (such as /etc/issue on linux, or maybe some
> hardware graphics card or cpu capability information) into the build
> to distinguish the final hash, and make different build-time
> assertions in the nix expression. But what about rejecting or
> accepting distributed builds? You could use your scheduler to make
> similar distinctions, but it seems the distinctions should be defined
> by the nix expressions in question, not the scheduler. This would
> provide consistent behavior for both distributed and command-line
> builds. For example, i would want a test that depends on sse3 to be
> rejected similarly when run as a distributed or local nix-instantiate
> build, and to have the rejection in the distributed case be evaluated
> without overhead.
>
> x86_64 systems double as i686 systems using the personality() syscall,
> but could there be a more general mechanism for overloading a node's
> platform? I'm perfectly willing to define it statically and per-system
> at the nix configuration level. It seems just allowing a system to
> trust multiple platforms might be a very simple answer to all of the
> above. Then the administrator could make completely arbitrary
> distinctions on which systems will build which "platforms" (you can do
> this right now but must pick exactly one platform for a given
> evaluation AFAIK). Permuting different configuration.nix files would
> be pretty annoying for builds going through daemons and a distributed
> build environment.
>
> Thanks for reading
>
> -nate
> _______________________________________________
> nix-dev mailing list
> nix-dev at cs.uu.nl
> https://mail.cs.uu.nl/mailman/listinfo/nix-dev
>

Hi Nate,
I think by it's very design the nix developers want nix to be as pure
as possible and are striving (And working extremely hard I might add)
To achieve that goal where ever feasabily possible. So to seek
impurity in nix is to to seek something that is the exact opposite of
it's design. Rpm, deb, etc are all impure enough to do do exactly what
you want and I think it's the wrong thing to do to make nix behave in
the impure manner that other package managers do. The single most
useful and interesting feature that the purity hepls to provide is the
rollback. Apart from other things, this feature (Which none of the
major packaging types have and IMO makes nix hands down infinitely
better by design than other packaging types) Would either suffer or
dissapear altogether if nix was to be used in an unpure manner;
without some very major changes in nix itself.
Nix purity is such a key design concept that I'm pretty sure an
impure/Pure switch would create a massive amount of problems and
likely be widely unsupported.
Deploying NixOs or using a combination of nix and rpm, deb, etc on
your $INSERT_FAVORITE_LINUX_DISTRO_HERE, Will likely do essentially
what you want and I think that the features that result from the
purity strived for in nix out weigh pretty much anything available in
any of other package manager out there.
Impurity is certainly something that I dissagree strongly about
catering for. I believe that all software should strive to be "Pure"
But it's an interesting topic.

Thanks,
Tony