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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
