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

[Nicolas Pierron]

On Tue, Feb 24, 2009 at 10:00, Ludovic Courtès <ludo at gnu.org> wrote:
> Hi,
>
> Nicolas Pierron
> <nicolas.b.pierron at gmail.com> writes:
>
>> On Tue, Feb 24, 2009 at 00:25, Ludovic Courtès <ludo at gnu.org> wrote:
>>> Nicolas Pierron
>>> <nicolas.b.pierron at gmail.com> writes:
>
>>>> 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?
>
> Sorry, I was referring to the "extensible activation script" item.
>
>> The activation script modification was only to tackle some
>> dependencies and check if we can easily write a script components in
>> multiple files.  The current version is working but there are still
>> some writing issues to make this look nicer.
>
> You're referring to the `script' attribute, `aggregateScripts', etc., as
> a replacement for `activate-configuration.sh', right?

Yes.

> I see only two uses of "script =" in the `fix-style' branch: one in
> `activate-configuration.nix' itself and the other in
> `upstart-jobs/xserver/displayManager/default.nix'.

And they are not related to each other.  If you want to see all
reference to the activation script, I suggest you to search for the
option name, which is not script but activationScript.

In activate-configuration.nix there one mkOption which is put after
the name activationScripts.  This name is now declared as an option.
This option expect to have an attribute set which is containing text
with dependencies.  All attribute sets are merge with the merge
function provided in the option.  The result provided by this option
is NOT the result of the merge function because there is an apply
function declared.  The apply function use the result of the merge
function to give it a user friendly representation.  In this case the
user friendly representation is a set containing the list of snippet
created in all modules and a script which contains all snippets.

This way, also stuff related to the creation of the activation script
is containing in system/activate-configuration.nix.  This file does
not contains default scripts because that is not the goal of this
module to give any content.  Other modules may need an activation
script and are candidate to add a new part of the activation script.
This new part may depends on features and may provide a new feature.
The list of snippets provided by the activationScripts option is used
to fetch features on which your new part is depending on.

> The new `system-options.nix' file contains large excerpts from
> `activate-configuration.sh' in a call to `FullDepEntry' (what's that?!),
> but the attribute is not named `script' as I expected.

In deed, that is the writing issue I was referring to.  The
FullDepEntry is a function used to organized text by looking at their
dependencies.  So each activation script may have dependencies defined
by other modules and allow you to define other part of the activation
script in other modules.  Have a look at /etc/default.nix

> Also, I suppose the order in which activation script snippets are
> concatenated is unspecified, or rather it's the alphabetical order of
> the name of the attributes they're bound to, right?  That looks fragile
> to me.

First all snippet are collected in an unknown order and they are
sorted by looking at their dependencies.

> Overall, I find it hard to follow what ends up in the activation script
> and where.  I'm also under the impression that there are a number of
> "alternative" features slipping in (`FullDepEntry', `noDepEntry', etc.)
> while I'd rather live without them.

Why wouldn't I use an existing code?

>>> If we are confident that Upstart jobs won't break, then I'm OK with the
>>> merge.
>>
>> I am not entirely confident with all upstart-jobs that I have
>> converted because I am not using all of them.  I have converted them
>> because they seemed simple to convert, so if there is any error, this
>> should not be a very hard to find it.
>
> How about the activation script itself and other "side changes"?  I
> would find it easier if we could selectively merge what we want rather
> that one large chunk of assorted changes.

You are free to try, but the activation script stuff is used by some
parts of the branch like user-groups activation, etc activation.  This
is useful because it allow you to extend the activation script (for
example, why do we need an upstart-job to add a guest user ?)

>>> (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.)
>>
>> All patches of the trunk have already been imported inside the branch,
>
> Yes, that's what I meant by "blurring the revision history": Git-side
> merges and cherry-picks aren't reflected in SVN.

In fact the last cherry-picks I've done are reflected into SVN ...

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron
- If you are doing something twice then you should try to do it once.