It is proposed that we move the executing of our build.sh shell script, from the rpm %posttrans scriptlet, to a one-shot systemd service that runs if of our .venv directory is not found. Our Python virtual environment is a pre-requisite of our other services and as such we can more easily user surface & develop this scripts failure/function if it is more properly located within our host OS's main orchestration.

Our current use of rpm's %posttrans scriptlet has surfaced a number of sensitivities/constraint, indicating that we are likely stretching the intended use of this somewhat constrained post rpm transaction scriptlet: i.e. contents are executed after the rpm package transaction has completed (we need our new build.sh to be in place after all) but we then face the constraints of a failed %posttrans execution and it's consequent failure to our other systemd services (no .venv). Moving/delaying build.sh's execution to the systemd services phase, which are auto-started post rpm install, means we can more properly place our required early OS arrangement under OS orchestration, rather than squeezing them into the constrained/limited last step of the packaging system.

It would also be significantly easier to develop further on build.sh it it were run from a more configurable environment such as systemd is designed to provide. As-is we have had a number of failures that pertain only to rpm's scriptlet env that otherwise are not seen in a regular terminal. And build.sh testing is then trivially accomplished by exercising it's proposed dedicated systemd script, rather than having to build an rpm and test that rpms's install/update function just to ensure we maintain function in that env.

We are also likely over-stepping the intended boundaries of %posttrans when we install additional programs; e.g our uninstall/install/upgrade maintenance of our build system Poetry: such as we do in build.sh. And additionally we are, more recently, using OS provided pipx to do this. Further complicating our requirements of a packaging system.

There are also odd corner cases to our current approach such as has recently been discovered in our latest installer build developments. See:
"Tumbleweed: build.sh fails as no /etc/locale.conf": rockstor/rockstor-installer#156

However this would dictate that our installer will have to have internet access in order that the first invocation of rockstor-build.service could download from PyPi our required .venv dependencies. But that is assumed for a modern OS instance anyway for all other OS updates. It would also remove the special case of our installer having a pre-build .venv when no other rpm has this: our rpm install/update auto-wipes the install location prior .venv directory: hence using this as an flag for build.sh's systemd service execution.