BuildFHSEnv for programs that are self updating

Help
1

Hello,

I’m curious to know, how is it possible to package complicated binaries softwares that have auto-updates procedure/plugin installations, and that use different paths, like /opt or /usr/bin to install themself and the dependencies ? I guess that BuildFHSEnv produces a write only path, so it will have troubles during installation of plugins right ?

Is there a writable equivalent of buildFHSenv (it could be possible to configure a folder outside the nix store to store the system) ? And what is the trick used by steam for example ?

3 Likes
2

Is there is a writable equivilant, or can it already do this?

3

If you know where it’s going to install the program, you could probably do something like:

runScript = writeShellScript "my-prog" ''
  if [ -x /path/to/final/command ]; then
    exec /path/to/final/command "$@"
  fi

  # Default to using nix provided binary
  exec my-prog "$@"
'';

If I remember correctly, the runScript gets ran inside of the fhs environment.

1 Like
4

Thanks, so what you suggests seems to work if the program installs itself in a writtable directory, but often many programs like to install themself in /opt (either by running as root, or by asking the user to do a dirty chmod in this folder)… But in BuildFHSEnv, I don’t think it is possible to write in this folder… at least it is not in steam-run:

$ steam-run bash
[leo@bestos:~/nixpkgs]$ sudo mkdir -p /opt/foo
sudo: Le fanion « no new privileges » (« pas de nouveau privilèges ») est défini. Il empêche sudo de s'exécuter en tant que root.
sudo: Si sudo est exécuté dans un conteneur, vous devrez ajuster la configuration du conteneur pour désactiver ce fanion.

[leo@bestos:~/nixpkgs]$ mkdir -p /opt/foo
mkdir: cannot create directory ‘/opt/foo’: Permission denied

I think I can imagine a solution where I would use bwrap to link /opt to a folder that can be written by the user. I can see an option extraBwrapArgs to add more arguments to bwrap… the main issue right now is that there is no way to create this folder in the user home in the current bwrap script… my current idea for this would be to create a wrapper around the bwrap wrapper that creates the folder in the user directory, and to use extraBwrapArgs to bind mount as read-write this directory in /opt… I see no obvious reason why this would fail.

It would also be way cleaner I think to have a writable FS overlay mechanism, where the overlay is saved in the user home for instance… this way we could install in a read-only /opt the usual installation for users, and then to the user could upgrade transparently, the update being kept in a FS overlay somewhere in its system. But I don’t know if such packages occur a lot in real life?

5

Yeah, my solution was to wrap the program and run in a dir like /var/lib/something