Nixpkgs: binutils and gcc manpages hidden by wrappers

[bgamari]

Issue description

The gcc and bin-utils wrappers don't expose the underlying derivations' man outputs.

Steps to reproduce

1. nix run nixpkgs.binutils.man -c man ld
2. Notice that the manpage is not found

Technical details

 - system: `"x86_64-linux"`
 - host os: `Linux 4.16.14, NixOS, 18.03.132646.08d245eb31a (Impala)`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 1.12pre5788_e3013543`
 - channels(root): `"nixos-18.03.132646.08d245eb31a, nixpkgs-18.09pre142651.95a8cb3ade1"`
 - channels(ben): `"nixpkgs-18.03pre126020.931a0b8be80"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs`

[bgamari]

@Ericson2314, perhaps you know of an easy way to resolve this? Perhaps just symlink the manpages into the wrappers' output?

[Infinisil]

It seems to only propagate man pages via propagated-user-env-packages:
https://github.com/NixOS/nixpkgs/blob/bf2a009380ab57f647f4c2e4cc531721aaa32847/pkgs/build-support/cc-wrapper/default.nix#L261-L269

This has the problem of only working when you actually install it into a profile, see https://github.com/NixOS/nixpkgs/issues/43049.

The fix would be to add something like

ln -s ${cc.man}/share $man

[matthewbauer]

@bgamari nix run has no knowledge of MANPATH. It only touches PATH. I think there may be a way to get MANPATH set based on PATH but I have never gotten that to work (multiple outputs probably break it).

For now you can do:

MANPATH=$(nix-build -E 'with import <nixpkgs> {}; lib.getOutput "man" stdenv.cc.bintools.bintools')/share/man man ld
MANPATH=$(nix-build -E 'with import <nixpkgs> {}; lib.getOutput "man" stdenv.cc.cc')/share/man man gcc

We definitely need a more versatile solution for this though.

A lot of people have setups to collect all of the manpages to install:

{
  packageOverrides = pkgs: with pkgs; {
    manpages = buildEnv {
      name = "manpages";
      paths = [ stdenv.cc.cc stdenv.cc.bintools.bintools ];
      extraOutputsToInstall = ["man"];
      pathsToLink = [ "/share/man" ];
    };
  };
}

Then you can just do nix-env -iA manpages. Then just do export MANPATH=$HOME/.nix-profile/share/man. But this is kind of a high bar to setup correctly.

[Ericson2314]

Yes this is just a mistake @oxij and I forgot to correct. It is done correctly in bintools-wrapper with nix-support/propagated-build-inputs, which is strictly stronger. The two wrapper scripts should work the same way.

[oxij]

@Ericson2314 I see, yep, that's a bug. Do you want me to fix this or do you want to do this yourself?

[Ericson2314]

To be clear it's really my fault, not yours :). I added the binutils one and didn't update the original, so I just didn't finish the job. You didn't touch the propagation part at al, so that would have been an out out of scope change.

That said, if you could do this I'd really appreciate it. I have a few other things to tackle.

[oxij]

See #44516.

[oxij]

I think #44558 actually fixes this. At least I can see both man and info for both gcc and ld in a minimal NixOS VM.

[teto]

Does that solve it for readelf too ? I couldn't get access to the man either (https://linux.die.net/man/1/readelf)

[oxij]

Yes, readelf too. But the patches are in staging, so it would take awhile till they hit the channels.

[oxij]

Patches hit master recently. I think this should now be closed.

[Profpatsch]

Was reverted in https://github.com/NixOS/nixpkgs/commit/c981787db951afb11c1328461df82d4277ebec07

[Ericson2314]

:/

[oxij]

In c981787db951afb11c1328461df82d4277ebec07 and fa412972091538376d1d4ffd446803b5d9385cbb, to be precise.

@edolstra, what exactly was not to your liking there? Reverting bugfixes without explanation isn't nice.

Do you want binutils-wrapper to put docs into propagated-user-env-packages like cc-wrapper did (and does again after these reverts) or what? If yes, then why? I think symlinking is a cleaner solution, as, I think, wrappers should just reexport outputs of their inputs when possible.

If Nixpkgs was SLNOS and SLNOS had centralized committer list like Nixpkgs I'd seriously think about removing you from that list after this and 4d1332e507fe55103bc5ddd0a384447dc7833e12.

Did either of those break anything?

[oxij]

Correction. There's also fde7296a4749efadbeb8b608b7b4cc01c3a6e6d7, so bintools already does the propagated-user-env-packages thing on master.

I still don't understand why these changes were made, though. Please explain, @edolstra -sensei!

I made #46115 with an edited revert. I think the first patch over master there needs to be reapplied again either way (unless it breaks something I'm not aware of) as that change did a useful and, I'd hope, non-controversial thing. The symlinking change is now a separate patch (which I still like).

[edolstra]

@oxij Don't worry, I have no desire to contribute to SLNOS.

Turning this around, I don't understand why these changes (moving from propagatedUserEnvPackages to symlinks) were made in the first place. Why are symlinks better?

[Ericson2314]

@edolstra so nix-shell -p stdenv.cc.man works

[edolstra]

nix run stdenv.cc.man works (with Nix 2.1).

[oxij]

@edolstra

Don't worry, I have no desire to contribute to SLNOS.

My point is that a polite way do a revert of a recently discussed and accepted change is, at the very least, to make a PR and mention the author of the changes in question.

I think that shooing PRs with "this needs mode discussion, hence this needs to go through RFC process" while commiting reverts straight to master without discussion is hypocrisy.

so nix-shell -p stdenv.cc.man works

That, and it also allows to control things directly via outputsToInstall which is used by documentation module of NixOS. Without the symlinking change that module can't do its thing for environment.systemPackages = [ binutils gcc ];

[Ericson2314]

I can't get even nix run stdenv.cc.cc.man to work on whatever NixOS version I am on, so I am switching to a newer one.

[oxij]

Without the symlinking change that module can't do its thing for environment.systemPackages = [ binutils gcc ];

Correction. I checked and buildEnv does handle this indirection properly, so this argument is moot.

So, I only have the following pros of symlinking left:

• simpler,
• uses 4 inodes less (two intermediate directories x2 for man and info),
• direct references like "export MANPATH=${stdenv.cc.man}/share/man" simply work (which, I think, @Ericson2314 meant in the above).

[Profpatsch]

I opened a documentation request issue https://github.com/NixOS/nixpkgs/issues/46141. If we document these, tooling can add support to understand them (like nix 2.1 does).

[oxij]

So, a day and several hours of experiments later, I still think the correct way to proceed on the issue is to revert the reverts, i.e. merge #46115 as is (I also edited the reverted reverts a tiny bit there).

I wrote an explanation why the first patch of #46115 is the correct way to proceed on the issue in https://github.com/NixOS/nixpkgs/pull/46119#issuecomment-419091869 (also see the changes in #46119 to see the problem I didn't know I accidentally fixed it in #44558). Since I don't see any actual arguments against using symlinks, I think the second patch of #46115 should be applied too.

Hence, I would merge #46115 as is.

[oxij]

This was fixed with #46115.