[Nix-dev] Distribution compatibility

[Mathnerd314]

On 12/13/2012 12:40 AM, Michael Raskin wrote:
>> 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...
The goal is to be able to install any system and have it managed 
completely within Nix. E.g. point Nix at an install of some 
(non-obscure) linux distro and have it turn into a working install of 
NixOS, with packages from that distro imported into the Nix store.
>
> It may be interesting, but I think some clarification is needed before
> anything can be said.
That's why this is an email and not a pull request. :-)
>
>> In a perfect world, I envision having multiple systems running at the
> Multiple systems running implies multiple kernel versions sometimes.
Well, if they're different OS's, then of course they'd have different 
kernels. That's why virtualization is needed, so that the systems can 
run concurrently.
But on the other hand, it would be nice to be able to run them without 
virtualization if they used the same kernel and mostly-compatible init 
systems. In particular, I'd like to be able to run user-level 
applications from other distributions in Nix.
>
>> 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.
I guess I shouldn't have brought it up, since Qubes isn't actually that 
relevant to what I want to do. But the Qubes developers are looking for 
a better way to build their VM images; IIRC they're just using a bunch 
of hand-written bash scripts now.
>   So you want a replacement for Chef/Puppet,
> like Disnix/Charon but with support for Nix configuration of non-NixOS
> systems?
Actually, I want the reverse: I want to take an installation of some OS 
and turn it into a Nix configuration.

The way you suggest, from configuration to installation, seems to 
already be implemented; e.g. it looks like Hydra builds VM's all the 
time to compile things for Fedora and Debian. I will improve the 
image-building algorithm to be less dependent on the target 
distribution's packaging tools, but my process will be to first get a 
perfect installation->configuration->installation round trip and then to 
shrink the configuration data into something that's distribution-portable.
>
>> repository into NixPkgs.
> Which is completely orthogonal topic.
So now you hopefully see why this isn't completely orthogonal; in order 
to go from other-OS to Nix, I have to have some configuration to map the 
system to. I could just pull in all of the different package 
repositories as part of my configuration, and will probably start by 
doing that, but there's a lot of duplicated information in there that 
could be shared with nixpkgs.
>
>> 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.
Well, the binary packages are what's installed on the system, so I need 
to maintain a list of those in the configuration. To shrink that list, 
it would be good to use a solver during the configuration->installation 
phase and prune to user-requested or top-level packages. But I guess 
there's no reason to expect that to be built-in to Nix.
>
> Now, separating global state modification from package-local actions is
> hard.
I'm taking a conservative approach to solving that problem; I want to 
look at the global state and attribute whatever I can to package-local 
actions. The rest (e.g. things under /home) I'll just keep in a file 
system and copy/overwrite over during the installation phase.
>
> 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.
I think assuming transitivity of packages dependencies is OK. The 
alternative is some sort of file-based tracking.

Their packaging guidelines state that they assume you have anything 
marked "required" or "essential" installed, as well as build-essential 
for building packages; are there any other common-sense assumptions?
>
>> 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.
Yeah, sorry, I was looking at hack-nix and got confused by his terminology.
>
> 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.
Once you have the Debian packages, you can start thinking about swapping 
out Debian dependencies with other dependencies. So it's more flexible 
than 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.
Well, I could put myself as the maintainer. But it's probably best to 
stay away from Hydra for the time being.

-- Mathnerd314