The reason behind this is to avoid breaking NixOps while releasing
version 1.0 of nixpart. We could also use nixpart and nixpart1, but the
goal is to have nixpart as a generic part of NixOS instead of being only
used specifically for the Hetzner backend of NixOps.
Which essentially means: The partition syntax will change to be based on
attribute sets and we no longer need to use Kickstart syntax. And that's
the main reason why it will break in version 1.0.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Leaving this just in buildInputs won't help here, because the project
using Paramiko will need pycrypto in any case.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It's bad to have the kernel config scattered across two places. (This
should also be done for the other architectures.)
Also, restore Xen and KVM guest support in Linux 3.10.
Having N different copies of the NixOS kernel configuration is bad
because these copies tend to diverge. For instance, our 3.10 config
lacked some modules that were enabled in older configs, probably
because the 3.10 config had been copied off an earlier version of some
older kernel config.
So now there is a single kernel config in common-config.nix. It has a
few conditionals to deal with new/removed kernel options, but
otherwise it's pretty straightforward.
Also, a lot of cut&paste boilerplate between the kernel Nix
expressions is gone (such as preConfigure).
It doesn't make sense to build tools/applications with three different
python interpreter versions, so move them out of python modules list.
Also reverts 53ffc6e0ef.
We cannot import the packages from all of these three packages sets into
the global namespace, because they are indistinguishable. For example:
$ nix-env -qaP \* | grep pylint
pypyPackages.pylint pylint-0.26.0
python33Packages.pylint pylint-0.26.0
python27Packages.pylint pylint-0.26.0
When someone tries to install pylint by running "nix-env -i pylint",
then it's impossible to tell which one of these three versions was
chosen.
I can think of two ways to remedy this problem with recurseIntoAttrs:
1) Bake the name of the Python interpreter into every package's name,
i.e. offer "python27-pylint", "python33-pylint", and so on.
2) Ensure that all non-default package sets mark all their packages
'lowPrio' to unsure that the choice during installation is
deterministic.
