Skip to content

Commit

Permalink
unixtools: link instead of copying
Browse files Browse the repository at this point in the history
This is better for disk space.
  • Loading branch information
matthewbauer committed Jul 9, 2018
1 parent 7e4ce2c commit f1a14f9
Showing 1 changed file with 8 additions and 5 deletions.
13 changes: 8 additions & 5 deletions pkgs/top-level/unix-tools.nix
Original file line number Diff line number Diff line change
Expand Up @@ -22,16 +22,19 @@ let
in runCommand "${cmd}-${version}" {
meta.platforms = map (n: { kernel.name = n; }) (attrNames providers);
passthru = { inherit provider; };
preferLocalBuild = true;
} ''
if ! [ -x "${bin}" ]; then
echo "Cannot find command ${cmd}"
if ! [ -x ${bin} ]; then
echo Cannot find command ${cmd}
exit 1
fi
install -D "${bin}" "$out/bin/${cmd}"
mkdir -p $out/bin
ln -s ${bin} $out/bin/${cmd}
if [ -f "${manpage}" ]; then
install -D "${manpage}" $out/share/man/man1/${cmd}.1.gz
if [ -f ${manpage} ]; then
mkdir -p $out/share/man/man1
ln -s ${manpage} $out/share/man/man1/${cmd}.1.gz
fi
'';

Expand Down

2 comments on commit f1a14f9

@dtzWill
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this better for space?

Optimized store will deduplicate anyway, right? Will NAR size be reduced or are links dereferenced?

Copying has potential benefit of avoiding pulling in the full closure of the original package, if all that's needed is a small header or utility. Not sure how important that is here....

@matthewbauer
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not very familiar with how nix-store --optimise works so it might not be necessary. There is still a benefit here I think in getting Nix to build everything locally. You just have to download procps once instead of the individual command for ps, watch, etc.

My experience has been that most of the binaries still retain references to their closure even when copying. So you end up getting both copies in your closure:

$ du -sch $(nix-store -qR $(nix-build -A ps channel:nixpkgs-unstable))
124K	/nix/store/qscgcniqpv7d9zi6frcwbkmrw694lhyp-ps-1003.1-2008
1.7M	/nix/store/g9ajw7rw27ysf165jkljs3m9ki4y5flp-procps-3.3.15
7.8M	/nix/store/q8rg4mca5zqv98arpxd7164pqa72hf1n-ncurses-6.1
27M	/nix/store/83lrbvbmxrgv7iz49mgd42yvhi473xp6-glibc-2.27
36M	total
$ du -sch $(nix-store -qR $(nix-build -A procps channel:nixpkgs-unstable)) | sort -h
1.7M	/nix/store/g9ajw7rw27ysf165jkljs3m9ki4y5flp-procps-3.3.15
7.8M	/nix/store/q8rg4mca5zqv98arpxd7164pqa72hf1n-ncurses-6.1
27M	/nix/store/83lrbvbmxrgv7iz49mgd42yvhi473xp6-glibc-2.27
36M	total
$ nix why-depends -a /nix/store/qscgcniqpv7d9zi6frcwbkmrw694lhyp-ps-1003.1-2008 /nix/store/g9ajw7rw27ysf165jkljs3m9ki4y5flp-procps-3.3.15
/nix/store/qscgcniqpv7d9zi6frcwbkmrw694lhyp-ps-1003.1-2008
╚═══bin/ps: …BC_2.2.5.LIBPROCPS_0./nix/store/g9ajw7rw27ysf165jkljs3m9ki4y5flp-procps-3.3.15/lib:/nix/store/83…
    => /nix/store/g9ajw7rw27ysf165jkljs3m9ki4y5flp-procps-3.3.15

It must have to do with linking to libprocps? But regardless of all of that you are probably going to have procps downloaded on your system at some point (some things link to ). unix-tools /should/ support multiple outputs if we ever get them in procps or util-linux but I am still thinking that linking would be a better idea.

Please sign in to comment.