The z-push-common package executes "z-push-admin -a fixstates" when being installed/upgraded.
While this works on most systems this could be an issue on big systems.
"z-push-admin -a fixstates" could run for a very long time (hours) on systems with many states.
While this is still necessary, it shouldn't block the installation or even fail preventing packages from being updated.
There are a few approaches:
in the postinst script, check the size of the state directory before executing fixstates at all. This would require the main config file to be parsed to extract the correct path and wouldn't work in case of e.g. the sql state machine. We also need to define an arbitrary value of what we consider "too big" (e.g. 1GB+?)
- pass an additional flag to z-push-admin telling that fixstates is being executed automatically (upgrading). The fixstate process could then differentiate and do one of the following:
Fixstates could check the size/amount of states and only run if it's less than X MB/GB. This would also need the definition of an arbitrary value and we consider "too big" and might not reflect the amount of time really required to execute this action (e.g. ssd disk would probably boost speed here). This would also work with the sql backend (IStateMachine interface needs to be extended with a "get size" method).
- Fixstates evaluates a hidden config option: IGNORE_FIXSTATES_ON_UPGRADE, default false. Fixstates then only runs on upgrade if this is set to false. On systems where the admin knows that this takes too long, it could be disabled on upgrade by setting it to true (adding the entire definition).
In all cases, if fixstates is not executed during the upgrade it still needs to run afterwards. There should be a well visible note/warning in the upgrade output telling the admin fixstates is required to run.