ghostscript: wrap binaries to add correct PATH

[SharzyL]

Description of changes

For scripts in ${ghostscript}/bin, they are not properly wrapped to put the binaries in PATH. When running them without packages in PATH, the scripts complain command not found. For example,

env -i nix shell p#ghostscript_headless -c ps2pdf
/nix/store/qg3n3ncn0hsi94ljr20m7f5w4kpxhqxg-ghostscript-9.56.1/bin/ps2pdf: line 8: dirname: command not found
/nix/store/qg3n3ncn0hsi94ljr20m7f5w4kpxhqxg-ghostscript-9.56.1/bin/ps2pdf14: line 3: dirname: command not found
/nix/store/qg3n3ncn0hsi94ljr20m7f5w4kpxhqxg-ghostscript-9.56.1/bin/ps2pdfwr: line 7: dirname: command not found
/nix/store/qg3n3ncn0hsi94ljr20m7f5w4kpxhqxg-ghostscript-9.56.1/bin/ps2pdfwr: line 24: basename: command not found

We wrapped these binaries to prefix the necessary packages to PATH.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.05 Release Notes (or backporting 22.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[SharzyL]

retarget staging now

[drupol]

This seems to be a legit change, but I would like to have the confirmation of more experienced reviewers.

[drupol]

@xworld21 @apfelkuchen6 Can you help me reviewing this PR ?

[xworld21]

Uhm, doesn't texlive depend on ghostscript already?

I suppose this can work in a pinch, but it should definitely be revised to depend directly on dvips. Passing an empty combine is almost always wrong – either wasteful (the required package can be used directly) or broken (e.g. because of missing fonts).

[apfelkuchen6]

The changes look reasonable to me now.

There are failing tests on darwin, these also failed before, right?

[xworld21]

Have you checked that $0 is interpreted correctly? I believe wrapProgram breaks $0 for non-binary executables. I suspect in this case it would only break the help output, showing e.g. .ps2pdf-wrapped instead of ps2pdf. But $0 is also used to find the sibling executables.

(By the way, for many of these scripts, a single substituteInPlace of the entire block GS_EXECUTABLE= ... GS_EXECUTABLE="$gs" with GS_EXECUTABLE='${out}/bin/gs' is enough, and possibly more appropriate than a wrapper.)

[SharzyL]

Yes, help output is showing .ps2pdf-wrapped since it is using basename $0.

Substituting GS_EXECUTABLE='${out}/bin/gs' seems not enough because we also need to bind some PATH from coreutils, gawk.

[xworld21]

Substituting GS_EXECUTABLE='${out}/bin/gs' seems not enough because we also need to bind some PATH from coreutils, gawk.

I meant, for quite a few scripts, the only coreutils usage is around GS_EXECUTABLE, so if you patch that away, there is no need for a wrapper. Other scripts do use gawk, basename, etc. so I agree with wrapping for those of course.