[Nix-dev] all-packages.nix and the unoverridable self.
roconnor at theorem.ca
roconnor at theorem.ca
Wed May 11 18:50:51 CEST 2016
I saw in that thread that you raised the same points that I have
https://github.com/NixOS/nixpkgs/pull/10851#issuecomment-157808356
But I didn't understand what the resolution was. I didn't see your
comment addressed.
Since you seem to understand what is going on, maybe you can explain how
users are supposed to locally override their linux kernel derivations?
I mean, at least the following has to be wrong:
linux = self.linuxPackages.kernel;
As written this is saying that linux is the kernel from the unoverriden
linuxPackages and if you have overriden linuxPackages with your own, tough
luck because we won't automatically update the definition of linux to be
consistent with your override.
How can that possibly be useful? Everytime one overrides linuxPackages
one must also remember to override linux. It makes no sense. If one used
linux = linuxPackages.kernel;
then linux and linuxPackages will always be consistent with each other.
On Sun, 8 May 2016, Ericson, John wrote:
> Nicolas intentionally kept `self` for such aliases as these. See the security updates PR (https://github.com/NixOS/nixpkgs/pull/10851) for the reasons why.
>
> On Sun, May 8, 2016 at 10:44 AM, <roconnor at theorem.ca> wrote:
> I haven't heard back from Nicolas yet.
>
> Perhaps I should put together a PR that removes the instances of self that I think are wrong so that we can discuss the issue.
>
> On Sun, 8 May 2016, Daniel Peebles wrote:
>
> Did you figure this out? I'm curious whether something got messed up in the recent changes.
>
> On Mon, May 2, 2016 at 2:23 AM, <roconnor at theorem.ca> wrote:
> Something seems wrong / bizzare with the recursion in all-packages.nix
>
> I've been trying to override linux_4_4 in my configuration.nix with the
> following:
>
> nixpkgs.config.packageOverrides = super:
> { linux_4_4 = super.linux_4_4.override { extraConfig = "CHROME_PLATFORMS y";
> kernelPatches = [ { name = "f10_sysrq"; patch = ./f10_sysrq.patch; } ]; };
> };
>
> but this no longer works. I've spent a few hours studying the issue.
> If I do the following chain of overrides upto the linuxPackages
> attribute
>
> nixpkgs.config.packageOverrides = super: rec
> { linux_4_4 = super.linux_4_4.override { extraConfig = "CHROME_PLATFORMS y";
> kernelPatches = [ { name = "f10_sysrq"; patch = ./f10_sysrq.patch; } ]; };
> linuxPackages_4_4 = super.recurseIntoAttrs (super.linuxPackagesFor
> linux_4_4 linuxPackages_4_4);
> linuxPackages = linuxPackages_4_4;
> linux = linuxPackages.kernel;
> };
>
> then it does work.
>
> I couldn't for the life of me understand why copying what is essentially
> the exact definitions of linuxPackages_4_4 and linuxPackages into my
> packageOverrides caused it to work. The whole point of the
> packageOverride mechanism is to invoke late-binding so that I don't have
> to override long chains.
>
> I traced the issue to the following strange set of definitions:
>
> all-packages.nix begins with something like this
>
> { ... }:
> self: pkgs:
>
> with pkgs;
>
> { ... }
>
> It is a function of three arguments, (1) a set of parameters, (2) a
> binding for self, (3) a binding for pkgs, and the with pkgs; bring all
> the definitions from pkgs into scope.
>
> This is called from top-level/default.nix with the following
> expression:
>
> allPackages = self: super:
> let res = import ./all-packages.nix allPackagesArgs res self;
> in res;
>
> So allPackageArgs contains the parameters, self gets bound to res, and
> pkgs get bound to self.
>
> The upshot of this is that within all-packages.nix self (which is bound
> to res) is the result of only evaluating all-packanges *with no
> overrides* while pkgs (which is bound to self) ends up late-bound and is
> the set of packges *with all overrides*
>
> So when linux and linuxPackages get bound using self in all-packages:
>
> # The current default kernel / kernel modules.
> linuxPackages = self.linuxPackages_4_4;
> linux = self.linuxPackages.kernel;
>
> The use of self here (and throughout the linuxPackage definitions) means
> that we are making reference to the *unoverridden package set*. This is
> why my packageOverrides of linux_4_4 did nothing, because the references
> to linux_4_4 inn all-packages.nix are prefixed with "self." which means
> it always gets the unoverriden packages.
>
> Is this really the desired behaviour? I think that all-packages.nix is
> full of many questionable uses of the "self." prefix. I suspect that
> people don't really understand that "self." means "give me the
> unoverriden version of packages". I think renaming "self" in
> all-packages.nix to "unoverridenPackages" would be a better name.
>
> --
> Russell O'Connor <http://r6.ca/>
> ``All talk about `theft,''' the general counsel of the American Graphophone
> Company wrote, ``is the merest claptrap, for there exists no property in
> ideas musical, literary or artistic, except as defined by statute.''
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
>
>
>
> --
> Russell O'Connor <http://r6.ca/>
> ``All talk about `theft,''' the general counsel of the American Graphophone
> Company wrote, ``is the merest claptrap, for there exists no property in
> ideas musical, literary or artistic, except as defined by statute.''
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
>
>
--
Russell O'Connor <http://r6.ca/>
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
More information about the nix-dev
mailing list