Missing man pages

[oxij]

Can we automatically check that for each package

• either there exist an output with actual .[1-9] files inside
• or the derivation explicitly says that they are not there?

[1] top-level issue #11499

[cleverca22]

chromium is also lacking man pages, they are in $out/share/share/man

[vcunat]

Maybe it would be more practical to have a separate linting tool for similar warnings.

[vcunat]

/cc @aszlig for the chromium case.

[Profpatsch]

separate linting tool for similar warnings

You mean linting on the outputs? Maybe that tool could search outputs for matching folders that might be in the wrong location.

[cleverca22]

i was also doing some arch linting for armv6 vs armv7 stuff
https://gist.github.com/cleverca22/eb2dad0edfed3cce93dc540e7561a795

the problem i had is that if you build an armv6 openssl on v7 capable cpu, v7 opcodes leak into the resulting binary

[vcunat]

Yes, I meant linting derivation outputs, maybe in a similar way to what lintian does.

BTW, @cleverca22, I fixed that chromium problem now.

[olejorgenb]

libxcb, libX11/xproto is also missing man pages.

Including documentation (especially for libraries) increases the closure size of packages. Is this an argument in play here or is it just by chance?

Maybe there should be a policy written somewhere?

If the closure size is a concern, is it possible to enable library documentation in a similar way to environment.enableDebugInfo?

[vcunat]

@abbradar: man3 pages are deleted by default; see $outputDevDoc in the manual. Adding a "devdoc" output gets the stuff moved there automatically (or "devman", as I read now).

[olejorgenb]

Is nix-env -iA nixos.multi_output_package.man the correct way to install such packages? (or adding it to systemPackages of course)

Note that those packages doesn't show up in the search at http://nixos.org/nixos/packages.html

EDIT: I now see that this is more or less described in the manual

[vcunat]

• We don't really consider them "separate packages", which is probably given by the history. (I think deb/rpm would do so, as they're more binary-centric. Their binary packages roughly correspond to our outputs; their source packages to our "packages"/derivations.)
• nix-env: yes, that's the intended way. The current default version of nix-env still installs all outputs always; that's only changed by nix-env: respect meta.outputsToInstall nix#815 and then your command will continue to work – it will only install that particular output and a default list otherwise (customizable per-package).
• systemPackages: yes, but additionally you can use a global option programs.man.enable; I now better describe that: fd26ad6.

[vcunat]

For reference, see the manual; feel free to point out stuff that should be better explained in there.

[Profpatsch]

systemPackages: yes, but additionally you can use a global option programs.man.enable; I now better describe that: fd26ad6.

Will that also enable all 3 pages? I remember lots of function docs were missing from my system a while ago.

[vcunat]

@Profpatsch: no, it won't. And most people don't want them, so I think it's good to have them separately. You can e.g. set environment.extraOutputsToInstall = [ "devdoc" ];; that will get you also gtk-doc, for example.

[Profpatsch]

Ah, very nice. Where could we document this? I think many devs don’t know about it.

[Profpatsch]

Also, wouldn’t it make sense to change it to outputsToInstall? This gives better flexibility and is also self-documenting.

[vcunat]

Some outputs are always installed by default. If you assign outputs in here, you shouldn't expect the original value to be overridden (or any you defined elsewhere – it's additive), which is why I put extra into the name.

[Profpatsch]

Right, the module system dictates the merge action on values.

Although this could be worked around by having the value be a function oldOutputList → newOutputList.

[vcunat]

No, each option can choose the merge function. (IIRC one can even supply a specific function for that option.)

[Profpatsch]

No, each option can choose the merge function.

Yeah, exactly.
outputsToInstall :: [outputs] -> [outputs]

Then the user can say

outputsToInstall = old: old ++ [ "devdoc" ];
outputsToInstall = const [ "out" "man" "devdoc" ];

or similar.

[vcunat]

Possibly, though to me that would seem an overkill for this option.

I guess all options could be unified to self: super: contents, and then we would add simple combinators (like const, mergeAttrs, appendList).

[oxij]

In #39049 I implemented some of the discussion here. Can somebody review (and merge), please?

[chreekat]

Given

documentation.dev.enable = true;
environment.systemPackages = [ pkgs.manpages ];

I think this issue can be closed? Granted, it would be nice if those two options were more discoverable, but that's a more general issue.

[Profpatsch]

I added an entry to the nixos wiki: https://nixos.wiki/wiki/Man_pages