New comment by ahesford on void-packages repository https://github.com/void-linux/void-packages/pull/32120#issuecomment-909351895 Comment: OK, I had some time to test this some more. I modied the `pycompile` trigger to always `exit 1` in place of the current `exit 0`, then tried installing an existing `python3-setuptools` package. (The existing package has the old `INSTALL` behavior that this PR fixes.) With the existing behavior, the `INSTALL` script consumes all trigger failures. Failures in the triggers may or may not cause some information to be printed to stdout (this obviously depends on the trigger scripts), but XBPS never sees a nonzero return code. It happily reports a successful installation: ``` [...] python3-setuptools-57.0.0_1: configuring ... Byte-compiling python3.9 code for module _distutils_hack... Byte-compiling python3.9 code for module pkg_resources... Byte-compiling python3.9 code for module setuptools... Updating ldconfig(8) cache... python3-setuptools-57.0.0_1: installed successfully. 7 downloaded, 7 installed, 0 updated, 7 configured, 0 removed. ``` The `xbps-install` process returns `0` and the package `python3-setuptools` shows up as installed and configured (`ii`) in the output of `xbps-query -l`. After rebuilding the `python3-setuptools` package to get an `INSTALL` script with fixed behavior, `xbps-install` instead reports ``` [...] python3-setuptools-57.0.0_2: configuring ... Byte-compiling python3.9 code for module pkg_resources... Byte-compiling python3.9 code for module setuptools... Byte-compiling python3.9 code for module _distutils_hack... Updating ldconfig(8) cache... ERROR: python3-setuptools-57.0.0_2: [configure] INSTALL script failed to execute the post ACTION: Operation not permitted Transaction failed! see above for errors. ``` and returns `1`. While the package is installed, it remains in an unconfigured state (`uu` in the output of `xbps-query -l`). In fact, every package installed as part of the transaction remains unconfigured. Attempted to reconfigure the packages causes the same error and leaves the packages unconfigured. Running `xbps-reconfigure -a` will leave all unconfigured packages in the same unconfigured state. However, those packages with triggers that do not fail can be individually configured in separate transactions. When removing a package, any removal triggers (like `pycompile` in this test) will report failure and abort the installation, leaving the package installed and whatever configuration state it was in before the removal. (Note that some part of the removal trigger may have run, so package state may have changed even though the package remains installed.) Even `xbps-remove -f` seems to fail here, so the package will be uninstallable as long as the removal hook fails. Thoughts: 1. I think propagating the install errors through to XBPS is the right behavior, and leaving the packages unconfigured is also correct. The configuration failed, so the package shouldn't be marked configured. However, who knows how many triggers leak unexpected nonzero returns harmlessly? We don't know. 2. Propagating the nonzero return on *remove* seems a bit risky here. The package will be effectively uninstallable until (or if) the removal hook can be run without errors. It's probably better to just swallow the error and allow the removal to proceed. I've updated the change to impose this behavior. 3. This behavior won't take effect in packages until they are rebuilt with the new `xbps-src` hook. I don't think there's a need to bulk rebuild everything; the fix can leak in by attrition.