[Nix-dev] Stable NixOS releases

[Vladimír Čunát]

On 05/21/2013 08:31 AM, Mathijs Kwik wrote:
> I also think there should be a distinction between "available" and "default".
> If our release cycle is more than a couple of weeks, chances are I
> want 1 or 2 more recent packages. I don't want to be forced to run
> master just because of this.
>
> If a new firefox/kde/kernel comes around, I would like it to be
> available in "stable". Of course this means manually
> setting/installing an explicit version, so it's clear I have to check
> if it works for me. On the next stable upgrade, I have to remove these
> overrides to go with the default stable version again.
>
> We can probably achieve this by splitting all-packages.nix into 2
> parts. A "pool" with (versioned) packages that follows upstream,
> shared between master and stable. And a "pinned" set, containing
> overrides to pin specific upstream versions. The end result (pkgs) is
> the merge between these 2. As our master is probably tracking upstream
> closely, its pinned set is mostly empty.
>
> Example:
>
> the pool contains {
>    firefox17 = ...;
>    firefox20 = ...; # support drops 05/2013
>    firefox21 = ...;
>
>    firefox_lts = firefox17;
>    firefox = firefox21;
> }
>
> master's pinnedVersions contains {
>    # nothing, just following upstram
> }
>
> while stable's pinnedVersions has {
>    firefox = firefox20;
> }

> This would mirror the exact upstream situation. The moment firefox20
> is no longer supported upstream, it is taken out of the pool. If
> "stable" depends on it, it should be clear that something has to be
> done. Either pin to firefox_lts, or move the expression to the pinned
> set, making clear it is nixos-maintained, not upstream.
>
> I think this layout allows us to track upstream closely, while still
> giving what's needed to maintain our own release-cycle. This would
> also make it far easier to maintain the nixpkgs stable branch, as it
> can just pull master every few days and see if there are overrides
> needed. A stable "release" is not much more than emptying
> pinnedVersions (apart from a few packages that track some lts by
> default in stable).

I don't think we should do this. I thought about similar setups, but 
IMHO they get way too much complicated for little gain. Reasons:

(1) Proposed solution. I plan to do something like this:
	let stable = (import ./nixpkgs-stable) {};
	    master = (import ./nixpkgs-master) {};
	in stable // {
	    inherit (master) firefox /*...*/;
	}

(2) Idea why it's so difficult to maintain: when updating e.g. firefox 
it's often needed to update some libs (like nspr, etc.), so we would 
have to split those as well and override them correctly for all other 
packages using them (this gets more complicated with deeply-depended 
libs like cairo). This is all solved by itself in (1).

I don't think we want a setup that would need significantly more work, 
our efforts are too spread out already.


Vlada


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3251 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20130521/d601fae6/attachment.bin