Feature proposal: one-time post-update hooks

[busykai]

We do need to have an option to run one-time post-update hook when we introduce breaking changes. For example, we may want to change the user configuration if it exists when we're changing the software default.

The feature would consist in running a code once conditionally. The condition, I am thinking, should be something like "run if upgrading from a version less than " where will be the Clear version that this code is associated with.

We may refrain from "doing the right thing" (tm) because our established practice/software configuration would be broken. Example (that actually led me to this idea): we want to disable root for ssh by default, but that we always allowed passwordless root. Therefore, there will be users that rely on it and will be broken. We could have a piece of code attached to the update which would reconfigure the system to leave it the way it was. In this example, it would configure sshd to allow passwordless root in /etc (if needed at all) while the update will change the default. The new installs will be using new default, the existing ones will be configured to override the default.

This is just one of the examples where we may need it.

An alternative to this could be using systemd, but it does not apply to all the environments and it does not preclude from bringing in the code that systemd will actually execute.

[cmarcelo]

In this example, it would configure sshd to allow passwordless root in /etc (if needed at all) while the update will change the default.

I do understand (and empathize) with the motivation of the feature, but changing /etc on behalf of the user, without even a mechanism to undo/redo the change, sounds a bit like trouble. Ideally the system should not touch /etc unless asked, but updates usually happen in the background, so this would be executed out of sight.

This is just one of the examples where we may need it.

Could you post more examples? (That will avoid focusing on particulars of one of the examples like I did above).

An alternative to this could be using systemd, but it does not apply to all the environments and it does not preclude from bringing in the code that systemd will actually execute.

Could you elaborate a bit on this?Maybe more detailed information on package versions and so on could be on the website or elsewhere.

About the proposal: will this apply solely for "format bumps"? ~~If not, how to make sure an "update script" is not ignored when updating to a version after the script was added?~~ (Edited to remove this last question, as is more of an implementation detail)

[busykai]

changing /etc on behalf of the user, without even a mechanism to undo/redo the change, sounds a bit like trouble. Ideally the system should not touch /etc unless asked, but updates usually happen in the background, so this would be executed out of sight.

I actually have just the example I gave (not allowing passwordless root). However, we simply cannot implement this without a feature similar to the one described because we cannot break the user setup (e.g. if one day it allows passwordless root in ssh and the other day it does not, it's a breaking change). So we are stuck with an non-recommended practice simply because we cannot update system without breaking it (potentially).

Could you post more examples? (That will avoid focusing on particulars of one of the examples like I did above).

I'm speculating, see the above, but introduction of a new user/group? Any changes in the defaults that we want to implement in a backward-compatible fashion? MOTD updates (see the #400)?

An alternative to this could be using systemd, but it does not apply to all the environments and it does not preclude from bringing in the code that systemd will actually execute. Could you elaborate a bit on this?

systemd does not work in containers (but swupd does). Also, using systemd involves installing files in /usr and cleaning them up (AFAIK). As opposed to one-time updates proposed which does not even have to be persistent on the system.