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

[Ludovic Courtès]

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?

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

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.

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.

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.

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

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

Thanks,
Ludo'.