[Nix-dev] Re: [Nix-commits] SVN commit: nix - r25375 - in nixpkgs/trunk/pkgs: desktops/kde-4.5/base-workspace tools/networking/knetworkmanager top-level

[Evgeny Egorochkin]

On Wednesday 05 January 2011 11:44:58 Eelco Dolstra wrote:
> On 01/04/2011 01:28 AM, Evgeny Egorochkin wrote:
> > Log:
> > knetwork-manager: package and enable support in KDE to see what is going
> > to break.
> > 
> > Added:
> >    nixpkgs/trunk/pkgs/tools/networking/knetworkmanager/
> >    nixpkgs/trunk/pkgs/tools/networking/knetworkmanager/live.nix
> 
> I've disabled this in all-packages.nix because the fetchgitrevision call
> breaks "nix-env -q".  This is because "nix-env -q" won't perform
> derivations during evaluation.
> 
> Also, perhaps these packages should be kept in a separate tree of "bleeding
> edge" developer/maintainer-targeted Nix expressions, since Nixpkgs should
> have at least some minimum level of stability :-)

I have already started to suspect that the issues introduced by 
fetchgitrevision the way it's implemented will not be fixable.

However, I disagree that this is the right way to address the problem.

KNetworkManager doesn't really have any releases to speak of. Distros use 
snapshots. The idea was to have a live build and then a stable snapshot of it:
knetworkmanager = knetworkmanager_live.override { revision = "..." };

As to fetchgitrevision in general, this function was intended to be overridden 
by the end user. For example, some people would prefer live builds to be only 
rebuilt once a day or once a week, and not everytime there's a new revision. 
Some other people, would rather have fetchgitrevision use a manifest file with 
repository+revision pairs that's generated by an external script.

If the default trunk-following implementation breaks stuff, let's replace it 
with a dummy that would output something that would not break evaluation and 
would throw an exception if you try to instantiate it. Users of live builds 
would override gitfetchrevision dummy with gitfetchrevisiondaily, 
gitfetchrevisionweekly or whatever it is they want.

As to stability, say we have kde4.6 in trunk, but the stable kde version is 
clearly and conveniently named as kde4. I don't see any problems with this or 
how live builds are different. You can't install the live build by accident 
afaik, or if you can, we can always lower the priority to fix this. And of 
course, someone using a live build should at least expect to face the issues 
that arise, which in many cases means no issues, because many projects try and 
maintain trunk in a working state, doing development in branches.

Oher projects use branches to efficiently release patches. One such package is 
redmine(which I'm packaging now). They have 0.* branches and 0.x.* releases. 
However, you can get fixes faster if you follow 0.* branch, instead of waiting 
for a maintenance release. All comits in the branch are maintenance only, 
keeping full compatibility. For a web app, getting security fixes faster is 
essential. The only nice way to implement this is trunk-following live builds. 
The user would do nixos-rebuild boot and if any of essential services are 
updated, activate the configuration as soon as they possibly can(eg avoiding 
downtime during peak hours).

Of course, in theory, you could wrap nixos-checkout and add some code to check 
for new revisions. But which solution is more practical? Which solution is 
more automated and solves more problems? Which solution requires the user to 
delve deeper into release/fix/patch approach of the app they use?

-- 
Evgeny