[Nix-dev] understanding Nix: dependencies

[Shea Levy]

On 01/10/2013 02:07 PM, Shea Levy wrote:
> On 01/10/2013 02:02 PM, Christopher Howard wrote:
>> A few questions, to help me understand how Nix works: Nix being a fully
>> deterministic package management system, does that mean that the exact
>> dependencies required by each package are fixed, i.e. do not change over
>> time for a specific package (version)? Does that include the
>> dependencies of those dependencies?
>
> Yes. If any dependency changes in any way (in version, in command used 
> to build it, etc.), the hash of the package will be different and thus 
> it will be rebuilt and installed into a different path in the store.
>
>> Assuming the answer to the proceeding two questions is yes, what is done
>> in the event that a deep dependency must be updated, while all the
>> higher level packages that use it do not? For example, each time openssl
>> is updated for security reasons, does this require you to release new
>> packages for hundreds of programs in your repository?
>
> The short answer is yes, but with binary patching provided by the 
> build farm it's not as bad as it sounds (you just download a diff 
> between the two outputs, which should be nearly identical).
>
> The long answer is: Currently, the way we build most of our packages 
> the build time dependencies (e.g. where do I get my library headers) 
> and the run time dependencies (e.g. which library do I link to) are 
> the same, so updating the run time dependencies will require a 
> rebuild. There are some proposed solutions to take one package built 
> against one version of a library and relink it to another without 
> recompiling it

OK, I've now implemented one such solution: 
https://github.com/NixOS/nixpkgs/commit/d1662d715514e6ef9d3dc29f132f1b3d8e608a18 
. So now in the event a rebuild would be too costly, you can still patch 
a broken/insecure dependency without breaking nix invariants.

> (so you still need to 'rebuild' the package, but the rebuild is 
> trivial), but a) libraries are never as good at compatibility as they 
> claim and b) we've found that the cost of recompiling everything isn't 
> actually all that high, all things considered. In general, the 
> question of whether and how to separate what something was compiled 
> against and what it uses is still open, but what we have for now works 
> very well.
>
>>
>>
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20130111/ab71cdea/attachment.html