Handle hardcoded paths in binary-only drivers / libraries?

Help
1

What’s the best practice to handle hardcoded paths in proprietary/binary-only drivers or libraries?

I want to use and package the proprietary SANE-scanner-drivers for Fujitsu / Ricoh SP-series document scanners (e.g. SP-1120, SP-1125, SP-1130), so I (and others) can use the scanners on NixOS. Fujitsu/Ricoh only provide a binary-only driver for Ubuntu. The libraries of this driver contain several hardcoded paths:

  • /etc/sane.d/
  • /opt/pfusp/
  • /usr/bin/ps
  • /usr/bin/grep

Since the driver does not find these paths, it fails.

So, what’s the best way here, so that the driver-libraries can find these paths/files?

  1. Quick-and-dirty: manually add symlinks to the system. Works, but…
  2. Patch the binary libraries? But the “new” paths are probably longer than the hardcoded ones, so that doesn’t work nicely.
  3. Patch the binaries, so the hardcoded paths point to /etc/… (/opt/pfusp → /etc/pfusp, /usr/bin → /etc/bin) and add symlinks via environment.etc (environment.etc."sane.d".source, environment.etc."pfusb".source, environment.etc."bin".source).
    But this looks like a workaround in an unintended way.
  4. buildFHSEnv? AFAIK does not work on libraries.
  5. buildFHSEnv or wrap all binaries using the driver (xsane, simple-scan, gscan2pdf)? Looks wrong.
  6. Create a custom nix-shell-configuration, which provides the paths, an run the binaries in there? Should work without patching the libraries, but seems a bit strange.
  7. write wrapper-libraries?
  8. …?

Currently, I’m considering and testing way 2 and 6, but maybe there’s a better way?

2

Which scanner are you looking for? Did you take a look at how it is implemented for ScanSnap drivers? (see nixpkgs/nixos/modules/services/hardware/sane.nix at a033e66ab94a6bedf2c3d58d93a36319d3cbbbaf · NixOS/nixpkgs · GitHub and nixpkgs/pkgs/applications/graphics/sane/backends/default.nix at a033e66ab94a6bedf2c3d58d93a36319d3cbbbaf · NixOS/nixpkgs · GitHub)

3

Especially Fujitsu/Ricoh SP-1130N. They do not belong to the SnapScan-Series, and it looks like they use a different driver-approach (but I have not (yet) read the SnapScan-driver details).

The pfusp-driver works, but the question is, how the hardcoded paths in there should ideally be “patched”.

4

No, but someone extracted the relevant files and those are provided as a package. Maybe even the extraction could be automated. That package is then provided to the sane backend.

5

No, that does not work.
As expected, the SnapScan-drivers work completely differently: There is an open-source-driver, which needs a firmware-file to work. The Fujitsu/Ricoh/PFU SP-series driver in contrast consists of binary-only libraries.

I’ve now packaged the Fujitsu/Ricoh/PFU SP-series driver using way 6: The package contains the driver and a nix-shell-configuration (+a shell-scipt to start it), which provides a modified root-filesystem with the necessary paths for the binary-only driver. To make the driver work, the user has to start this nix-shell and run e.g. scanimage, xsane, simple-scan or gscan2pdf from inside this shell.
Is this a recommended way, or is an other way (e.g. (3) or (7)?) recommended over (6)?

6

Sounds like maybe a bwrap wrapper might be what you need?

7

Yes, I’ve used bwrap in the nix-shell-configuration.