[Nix-dev] [***SPAM***] Re: Distribution compatibility

[Michael Raskin]

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

Erm. A noble, ambitious goal, and I feel I am too skeptical to give it
just treatment. I do use my own collection of out-in-the-blue technical
solutions, but this is too global.

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

It is not a patch submission because there is no patch... 

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

Well, a minimal ld trickery allows running things even without chroot...

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

I am afraid that this means manually writing rules for every service in 
every supported distribution...

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

Why would you even want to work with binary packages here? Converting 
binary package set to source package names seems simple enough. If you
care that much about saving HDD space.. well, I would say I have never 
seen any clear counterexample to "Nix is a tool to avoid sanity damage 
by paying with HDD space".

I guess that convertor of Debian source package definition to Nix
expressions that supposes minimal manual tuning would be nice anyway,
and whether it works fully automatically will have to be seen
afterwards.

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

Well, there are file-needed dependencies.

I am not sure that their assumptions about X11 libraries can be always
guaranteed by only following requires/essential links.

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

Well, if conversion is fully-automatic, that means that fixing packages
manually is a bad idea, and so the maintainer should only be set if the
package is forked from the converted version into a spearate development
line.

This also matches the desired Hydra behaviour...