Can't find a way to install gnumake info files to user environment


I’m trying to install GNU’s make info manuals to my user environment but from some reason they are not found in my ~/.nix-profile/share/info no matter what I do.

I tried the following:

  1. Running nix-env -iA
  2. Running nix-env -iA nixos-unstable.gnumake.all
    3, Running nix-env -iA nixos-unstable.gnumake while gnumake's meta.outputsToInstall is overrided in my ~/.config/nixpkgs/config.nix to include "info" as so:
    gnumake = pkgs.gnumake.overrideAttrs (oldAttrs: rec {
      meta.outputsToInstall = [ "info" "out" ];

As explained here.

I can see the package’s info files in /nix/store/...-gnumake-info/share/info/ but from some reason they are not linked to my profile! This problem is there for every package with and "info" output (e.g (using git grep in nixpkgs)

I noticed nix-env has -v flag which can be given multiple times and so make the log more and more verbose but I couldn’t find interesting information there… I’d be happy to hear only pointers as for how to debug this.

nix-env strikes again! This is one of the ways in which it’s a pain to use.

One possible-but-also-kind-of-awful workaround (which I use to get tmux’s man pages) is installing a derivations that produces a symlink to what you actually want:

echo 'with import <nixpkgs> {}; runCommandNoCC "make-info" {} "ln -s ${} $out" > make-info.nix
nix-env -f make-info.nix -i

Or if you have a declarative expression for your user environment, you can plonk it in there like I did.

That’s one hell of an ugly workaround… Thanks for suggesting it. Do you think it might be possible to create a package which will be named say gnumakeInfo that will be built using runCommandNoCC and that will only provide these .info files? If that will work or not, it can help further debug the issue…

runCommandNoCC produces a package, so that’s essentially what my example already does :slight_smile:

What is the actual cause of the problem here? nix-build -A '<nixpkgs>' gives me the expected result-info symlink that contains the info pages, but nix-env -iA actually installs instead. Why does that happen?

nix-env never installs the outputs you ask it to, I think it always uses outputsToInstall (but as @doronbehar noticed, overriding that doesn’t seem to work either). I’ve given up on trying to get it to do what I want in imperative use myself.

Thanks for joining the discussion @lilyball, I hope we’ll be able to make some progress here because from some reason this small issue really annoys me. Is there a command that could evaluate and print the value of arbitrary attributes? (I’m sure there is I just couldn’t find it in the manuals…)

I would like to know with the aid of this command the value of outputsToInstall with and without my ~/.config/nixpkgs/config.nix overriding it and with it.

Also, another question: Shouldn’t outputsToInstall include "info" in anycase? From what I figured out out of the manual, it seems this would be needed to be overrided only in case of "dev" or "devdoc" outputs being desired…

I find the quickest way to explore this is with nix-repl:

> nix repl
Welcome to Nix version 2.2.2. Type :? for help.

nix-repl> :l <nixpkgs>
Added 10579 variables.

nix-repl> gnumake.outputs
[ "out" "man" "info" ]

nix-repl> gnumake.meta.outputsToInstall
[ "out" "man" ]

nix-repl> (gnumake.overrideAttrs (oldAttrs: rec { meta.outputsToInstall = [ "info" "out" ]; })).meta.outputsToInstall
[ "info" "out" ]

You can also do once-off attribute exploration with nix eval, as in

> nix eval nixpkgs.gnumake.outputs
[ "out" "man" "info" ]

though this command can be rather confusing when trying to evaluate arbitrary expressions (it appears to me as though if the argument starts with a letter, it treats it as an attribute path with nixpkgs available, and if it starts with a paren it treats it as an arbitrary expression without nixpkgs in scope) so it’s mostly just useful for writing things like nix eval --raw nixpkgs.gnumake.meta.homepage (to print the URL of the package).

I’m not aware of where in the manual it defines the default behavior, but the default outputsToInstall for stdenv.mkDerivation is defined using the following rules:

  1. If outputs contains "bin", then use that. Otherwise if it includes "out" then use that. Otherwise use the first element of outputs.
  2. If outputs includes "man", add that to the output chosen in the previous step.

This means that for most packages outputsToInstall will end up as one of the following 4 values: [ "out" ], [ "out" "man" ], [ "bin" ], or [ "bin" "man" ]. The only way it will contain "info" is if outputs does not contain either "bin" or "out" and the first element of outputs is "info".

FWIW I just tested the following:

nix-env -p ./prof -f '<nixpkgs>' -iE 'f: (f {}).gnumake.overrideAttrs (oldAttr: rec { meta = oldAttr.meta // { outputsToInstall = [ "out" "man" "info" ]; }; })'

and it did in fact install gnumake’s info pages, so maybe your package override wasn’t set up correctly.

@lilyball Could you test the equivallant of that expression inside ~/.config/nixpkgs/config.nix?

When I added this:

gnumake = pkgs.gnumake.overrideAttrs (oldAttrs: rec {
  meta.outputsToInstall = [ "info" "out" ];

to ~/.config/nixpkgs/config.nix, and I ran the same commands in nix repl, I got the same results as if that override wasn’t there.

EDIT: I’ve also tested your nix-env command and it didn’t install the info pages. Did you verify it via ls -l ~/.nix-profile/share/info/

I just added that expression in an overlay (overlays are the replacement for packageOverrides) and nix repl shows gnumake.meta.outputsToInstall as [ "info" "out" ]. In addition, after installing it into a profile, I do see share/info/ I was installing it into a custom local profile so as to not interfere with my actual environment but the behavior should be identical.

Since you’re not seeing it in nix repl my guess is you’re doing something wrong with the packageOverrides. I suggest you remove it from that and instead create a file ~/.config/nixpkgs/overlays/gnumake.nix with the contents

self: super:

  gnumake = super.gnumake.overrideAttrs (oldAttrs: rec {
    meta = oldAttrs.meta // {
      outputsToInstall = oldAttrs.outputs;

Finally! Thank you so much @lilyball. I sort of always knew that overlays is the modern approach to these kind of stuff but the documentation is kind of misleading, Because this section, references this section which clearly suggest using config.nix and not overlays…

Yeah, the documentation is outdated. It’s a known issue. I wish someone who’s good at writing would submit a PR to update it.