[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
phreedom.stdin at gmail.com
Thu Jan 6 01:57:48 CET 2011
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
More information about the nix-dev
mailing list