[Nix-dev] Fwd: Reminder about nixpkgs branches

[Vladimír Čunát]

On 07/25/2014 12:58 AM, Mathnerd314 wrote:
>      > NixOS is inherently a
>      > state-centric system; it's not "this change broke my system" but
>     "version V of
>      > thing X is broken".
>
>     I don't know what this means.
>
> I believe darcs is pretty much the only example of a "change-based"
> system, so this is more a reply to Vladimír Čunát.

NixOS is state-centric in the sense that from particular nixpkgs 
state(s) and configuration.nix state you can generate a NixOS state. 
Then you can essentially only switch among these states. Doing things 
like "take this state but also apply a minor kernel update" isn't 
straightforward, although it's achievable if VCS-tracking 
configuration.nix and nix-version.

Darcs is probably still the only usable change-centric VCS, and 
unfortunately some issues on conflicts aren't well-resolved yet (and 
AFAIK noone knows how to do that yet).


> So I say go the other way: if you can't test the dynamic stuff completely, don't test it at all.

No, that's not a good approach. You can never completely test a program, 
as that's generally undecidable in principle. Besides, just to specify 
formally the correct behavior completely is infeasible (i.e. typically 
not worth the work).

> On the other hand nix-instantiate is (at least theoretically)
> system-independent so it is reasonable to run it over all packages; it
> can check syntax, types, etc. - basically everything static. But the
> dynamic stuff, e.g. Hydra's builds and tests, should only run as often
> as you want to release, not as often as you want to update a package.

Syntax is practically checked in the tarball job (for multiple 
platforms). Most errors in our experience are build time, fortunately, 
so Hydra does catch those already.

>     I don't see the connection with the extensional model.
>
> Since the extensional model only identifies the inputs, it automatically
> assumes that any two runs of a derivation are the same.

As I noted in the "intensional" github issue, exact build determinism 
will get much more important for most users after adopting an 
intensional scheme. (not less important as you seem to think)

>        environment.systemPackages = [ (builtins.storePath
>     /nix/store/gv67fwcwbyha77kxsmgcs41baqxh2ysi-firefox-31.0) ];
>
> There's no way to refer to "the result of calling fetchurl
> http://google.com on July 1st 2013", which can be described with the
> intensional model (a hash of the contents, as usual).

There is, and it's the same way again. Hash and name are the only things 
that affect the output path of fetchurl. In fact, fixed-output 
derivations are very close to the intensional model already.


>     The main advantage of the intensional model is that it allows
>     untrusted users to fetch binaries from untrusted binary caches.
>
> It also allows derivations to fetch or produce volatile or
> time-dependent data, which I think is a bigger advantage.

IMHO that typically brings more problems than worth. (due to nondeterminism)

> Before then, though, the term is meaningless; there is no
> way to implement a "purely functional downloader".

The current fetchurl does act as pure function. That's why have it. 
(assuming sha256 is securely collision-free on the things we use)

>     Switching to the intensional model would be a huge undertaking which
>     I don't see happening soon.
>
> Yeah, no disagreement there. Although we might have different
> definitions of "not soon"; I've often heard it defined as "never", while
> I hope it is closer to "in a few months" in this case.

Having it in 14.10 is IMHO practically impossible. As noted in the 
issue, we need to do (probably) lots of work on exact build determinism 
in nixpkgs before the switch as well.


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/20140725/054b640a/attachment.bin