Hi, On 29/07/12 10:41, Shea Levy wrote:
>> Could you say a bit more about what this means and what the advantages >> are? > > Basically, it allows you to build a kernel after configuring it with the > official kernel config mechanisms (e.g. make menuconfig) rather than using > our automated system. By trying to make as many options modular as possible, > the standard system is great for general use, but some users (e.g. me) may > not want or need all those modules and may prefer to configure their kernels > the traditional way. I imagine this could be done by adding an argument to the standard generic kernel builder to completely override the kernel config? > The feature autodetection is a big plus as well, as hopefully it will enable > NixOS to fail early if the kernel doesn't do enough for a given module to > work. That's pretty cool. >> Unfortunately using an import from a derivation means this shouldn't be in >> Nixpkgs right now. Won't this cause a build when I do "nix-env -qas"? > > No, since the attribute in nixpkgs is a function, not a derivation. The > import-from-derivation is only triggered when you call the function with your > config and kernel source, and if it's not desired then then you can pass in > features yourself as well. Ah, okay. Then it's not a problem. :-) > This was meant to be a supplement, not a replacement, so I thought there'd be > little harm in having it in master, but I can revert the merge for now if you > like. No, it's fine. I'm just somewhat concerned about experimental features in the Nixpkgs master that might end up not being used/maintained. -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
