[Nix-dev] Distribution compatibility

[Michael Raskin]

>It seems like Nix can be installed on pretty much any system (including 
>Windows?), but the reverse does not seem possible: why shouldn't one be 
>able to install any system on NixOS?

I cannot clearly understand what your actual goal is here...

It may be interesting, but I think some clarification is needed before
anything can be said.

>In a perfect world, I envision having multiple systems running at the 

Multiple systems running implies multiple kernel versions sometimes.

>same time a la Qubes (http://qubes-os.org/trac), all nicely managed
>using nix, but a good start is finding a way to stuff Debian's package 

Qubes uses Xen VMs, actually. So you want a replacement for Chef/Puppet,
like Disnix/Charon but with support for Nix configuration of non-NixOS
systems?

>repository into NixPkgs.

Which is completely orthogonal topic.

>Currently, it seems like installing Debian packages on NixOS requires 
>manually writing a derivation, and there are no tools to automate 
>writing such a derivation. There's also the question of whether the Nix
>package format is flexible enough to allow installing/breaking up 
>packages in something approximating "the Debian way," and whether the

Breaking up is not the real problem — and it is not even needed, as 
you should look at the source packages anyway.

Now, separating global state modification from package-local actions is
hard.

Also, Debian dependencies are way underspecified. I am not talking about
versions, I am talking about not separating what we call "buildInputs" 
and "propagatedBuildInputs" (which could be just ignored by declaring
that everything is propagated, however clumsy it is), and often making 
some common-sense assumptions about what would have to be installed 
anyway.

>dependency solver in Nix is powerful enough to handle ~26,000 new 
>packages, each with 3+ versions from the various debian-stable, 
>debian-testing, and debian-unstable repositories.

Dependency solver? Did you look at what Nix actually does? Generally,
we just give every package the set of library versions it needs without
bothering if we have three instances of glibc on the same system.

Well, the library versions it needs according to our best guess, if one
takes into account limited resources.

And what is the point of all it? Debian packages would have Debian
dependencies, so you would just get the same as you can have right now
with debootstrap.

>I looked over the Mancoosi project, and one of their tasks was 
>formalizing maintainer scripts into a DSL. I think they've stopped 
>(mostly), but EVOSS (the system they developed) is still up: 
>http://mancoosi.di.univaq.it/?page_id=36
>
>Presumably it wouldn't be too hard to take their translator and modify 
>it to output in a format that Nix can read instead of whatever DSL they 
>came up with, and then implement whatever glue code is needed to get Nix 
>to understand those. After that it's a question of whether the 
>infrastructure is up to it; even if Nix works perfectly (which it won't; 
>it doesn't have any sort of SAT solver but just brute-forces things,
>correct?), Hydra will run out of disk space. I expect these problems can 
>be mostly ignored because they're orthogonal to the actual packages.

Given that autogenerated packages will lack Nix-side maintainers, Hydra
will not even start to build them.

>Thoughts? Reasons this won't work that I'm missing?