[Nix-dev] Re: Merging fix-style branch into the trunk ?

Ludovic Courtès ludo at gnu.org
Tue Feb 24 00:25:49 CET 2009


Hi Nicolas,

Nicolas Pierron
<nicolas.b.pierron at gmail.com> writes:

> The previous evaluation system had the following problems:
> 1/ Users have to learn all Nix features to patch NixOS and to put
> their hands into the code in order to add services or primary
> features.

Hmm, the proposed approach makes a non-trivial use of lazy evaluation
for instance, while the current approach doesn't use any sophisticated
language feature.

> 2/ NixOS features are spread over multiple files without any clear links.

Here I agree that what you propose is a significant improvement.

> Main modifications made in this branch:
> - a few upstart-jobs conversion.
> - upstart-jobs/default.nix, etc/default.nix are configuration files.
> - extensible activation script.

Can you elaborate on this?  How does this relate to the main goal of the
branch?

> - system parts can be build in multiple files.
> - xserver handles multiple .. at the same time: windowsManager
> (compiz, wmii, ...), desktopManager (kde, kde 4, gnome, ...)

Again, how does it relate to what's discussed above?

> Do you want me to push these modifications in the main line ?

Did you somehow test those Upstart jobs that you didn't "upgrade" to the
new style to make sure they don't break?  It would be unfortunate if the
first `nixos-rebuild' after the merge broke many Upstart jobs people
rely on.

If we are confident that Upstart jobs won't break, then I'm OK with the
merge.

(BTW, merging this branch will blur revision history, which is
unpleasant.  I would recommend against using git-svn(1) for merges, and
so does the man page, but I guess it's too late now.)

Thanks,
Ludo'.




More information about the nix-dev mailing list