[Nix-dev] Questions about the all-packages fixpoint

Nicolas Pierron nicolas.b.pierron at nbp.name
Sat Mar 18 17:59:12 CET 2017


On Sat, Mar 18, 2017 at 3:27 PM, Benno Fünfstück
<benno.fuenfstueck at gmail.com> wrote:
> Nicolas Pierron <nicolas.b.pierron at nbp.name> schrieb am Fr., 17. März 2017
> um 22:36 Uhr:
>>
>> On Fri, Mar 17, 2017 at 9:38 PM, Benno Fünfstück
>> <benno.fuenfstueck at gmail.com> wrote:
>> > One thing that is nicer about `self.callPackage` though is that you can
>> > follow the rule "whenever taking something from self does not lead
>> > infinite
>> > recursion, take it from self" when writing overrides.
>>
>> And we should not advertise that, because this would lead to packages
>> which are not patched, under the rules of the future security-update
>> work.
>> So whatever you think this is simpler or not, this is incorrect, I
>> guess we could nullify these functions in the latest layer, preventing
>> callPackage to ever be used through `self`.
>
>
> Oh, why would that lead to not applying security updates? I'm not very
> familar with "future security-update work", but that sounds unexpected to
> me. What's so deeply magical about security updates?

The security-update branch needs to peel off the fix-point of Nixpkgs.
Then the patching behaviour is added in-between every package by doing
one more step of the Nixpkgs function.
This has the consequences of giving the following semantic to the
numbers of hops that you use to fetch the dependencies:
 - 0 hop: means that you are linking statically.  Any change of such
dependency would cause your package to be rebuilt.
 - 1 hop: means that you are linking dynamically. Any change of such
dependency would cause your package to be patched.
 - >1 hops: means nothing. Any change of such dependency would leave
your package to be unchanged.

Going through `self` is adding hops.  If you were to call
`self.callPackage` instead of `super.callPackage`, you would have 2
hops instead of 1 hop, because callPackage generate attribute set out
of `self`.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/


More information about the nix-dev mailing list