On 05/21/2013 09:19 AM, Mathijs Kwik wrote:
Vladimír Čunát <[email protected]> writes: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 /*...*/; }This is not a true override though. In the case of libraries, everything in stable will still be using the stable version. Often, this is ok, but I don't like having multiple versions installed.
It isn't but it should always work even with (2) problems. I believe we should be able to compose a simple override that would take package from master and dependencies from stable. That should catch most use cases, like you want to try a new version but don't need whole new closure; and for things like nspr you would just have to override the override :-)
(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).This can really become quite a large closure though, for example if we had a stdenv-updates merge in master.I don't think we want a setup that would need significantly more work, our efforts are too spread out already.I agree on that. If I want some new version of a package backported, it's probably easiest to just add it to stable myself (versioned of course).
I suppose, for packages like firefox we will do that. I think all agree that non-default attributes can take major changes even in stable release.
For example firefox is always versioned, so all changes could be just applied, only the default version switch ("firefox(Pkgs)" attr) would remain the same.
Vlada
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
