When adding modules to openresty, by either
- using `.override { modules = [ ..]; }` directly
- adding them to `services.nginx.additionalModules` or
- enabling e.g. something like `services.nginx.recommendedZstdSettings`
the build will then fail, as the actual `nginx` binary lands in
`nginx/bin/nginx` for openresty, and is only symlinked to `bin/nginx`
(and `bin/openresty`, for that matter).
This breaks the post-install script for nginx when removing references
to the aforementioned modules, since `remove-references-to` skips
symlinks. Thus, just read the symlink before in this case.
`readlink -fn` will read the symlink if it is one, otherwise just
returns the path itself.
The phase is also moved after the package-specific postInstall phase, at
that might move binaries around or create symlinks - as is the case for
openresty.
Can be easily reproduced using e.g.:
$ nix build --impure -E 'with import ./. {}; openresty.override { modules = [ nginxModules.zstd ]; }' -L
Signed-off-by: Christoph Heiss <christoph@c8h4.io>
I'm including the steps I took to update this package to help the next
committer. Time permitting, this should probably be codified as a
formal update script:
1. Clone the upstream hashicorp/vagrant repository
2. Check out the desired version tag
3. Run `bundle lock` within the repository to generate `Gemfile.lock`
4. Run `bundix` to generate a `gemset.nix`
5. Move `gemset.nix` to overwrite this package's `gemset.nix`
6. Remove the self-referential `vagrant` attribute of the gemset
7. Clone vagrant-libvirt/vagrant-libvirt and check out the desired tag (probably latest release tag)
8. (Maybe optional?) because `bundle lock` lacks the ability to exclude groups; comment out groups unrelated to a release like `development` and `test, otherwise dependency conflicts with vagrant's `gemset.nix` are likely.
9. Run `bundle lock` within the repository to generate `Gemfile.lock`
10. Run `bundix` to generate a `gemset.nix`
11. Move `gemset.nix` to overwrite this package's `gemset_libvirt.nix`
12. Edit the `vagrant-libvirt` gem attribute to change its source to rubygems and not a relative path
Aside from these specific steps, the normal package update steps apply (update version, set hash to `lib.fakeHash`, get the updated hash to replace the old).
