SYSTEM PATCH MANAGER
You can skip the introductory sections and jump directly to the end where the technical stuff is presented. In case you like that, you my came back here to read the premises.
Rationale
A system patch manager should be able to record the changes that are affecting the system and revert / apply them in a fail-safe way. This means that it SHOULD work from a console and it should work from a recovery image with minimum additional requisites, possibly none.
Adding a full scripting capability is a little more complex task than including such script into a package and running them because shell script can do arbitrary things and in some corner cases (and failures) can do untracked / unexpected things that cannot be reverted with counter-acting script (eg. post-install.sh → pre-remove.sh).
This is true also for RPM packages - mitigated by the fact that usually packages maintainers have a system test facility that allows them to validate the RPM packages for a wide variety of scenarios and different system configurations - plus - mitigated by the fact that RPM system is a well established way of installing / removing software which is in production since 1997.
Why do not use RPM to patch the system?
Because the RPM is a system to install software not to apply patches and do traceable system configuration changes. For sure some tools for this aim, exist out of there. Yes, they are named configuration management system. Usually they are tailored for a specific system or highly configurable for a class of system (eg. GNU/Linux distributions). The odd is that in SFOS end-users are used to use Patch Manager from the UI and a kind of integration with it would be easier to introduce them into this new dimension.
Moreover, there are many ways to track unexpected system changes, also. In particular inotify approach but can be a little tricky to use on a living system even if it will be probably a long term general solution or alternatively a filesystem that can provide a standard reliable changes log or snapshots by design.
Apply patches to the system can brick it
Breaking the system in making experiments with SFOS, which is equivalent to using it as any other GNU/Linux system as much as it can be considered similar, it is the main reason because you are using SFOS because there are no really other reason apart fairly tales and a matter of personal taste.
Backup before brick your root filesystem.
Technical approach
Therefore developing shell scripts that can be integrated with a slightly modified version of the current Patch Manager is the main way and storing the system patches into Web Catalog is also a good option to go, naturally.
Instead of start adding a generic and arbitrary shell scripting capability, I focused on system configurations and their system services. For this aim adding a header to the patch seems a reasonable easy way to cope with the most interesting and common cases.
This is a testing patch that is going for that way:
Here below an example of such a header for testing purposes:
#!/bin/bash ## this line for a patch which header is a shell script ############
##
## (C) 2023, Roberto A. Foglietta <roberto.foglietta@gmail.com>
## released under MIT (tlo.mit.edu) license terms
##
## This is a system patch header example for SailFish OS system patch manager
##
#\header #######################################################################
#
# type: system
# target: sfos
# services: dnsmasq connman
#
## optional fields using tabs instead of spaces just for test ##################
#
# name: dnsmasq-connman-integration # a comment
# provider: robang74 # another comment
# version: 0.1.1 # yes another one
#
## a repetition, a variant and an unrecognised fields just for test ############
#
# name : dnsmasq-connman-integration-not-fit # this should raise a warning
# services : dnsmasq, connman;
# string : "hello world"
#
#/header #######################################################################
#
## put the shell script body between this line and the --- end of header mark ##
---
Just a set of essential information which the vital part is:
services: dnsmasq connman
because everything else is for separate the volatile UI from the permanent system patches and to separate the application of those patches between the SFOS and your laptop/PC GNU/Linux system.
After all, the beauty of such approach is that can be used also for every GNU/Linux system and every others system which is reasonably similar and provides a shell compatible scripting environment.