Closed robang74 closed 1 year ago
This is already present functionality. As this section of Patchmanager's README denotes:
Patches can be too complex for Patchmanager's Web Catalog. In this case the developer may package the Patch as an RPM and upload it at https://openrepos.net/ or another user-accessible package repository. OpenRepos provides a category "Patches" and a tag "Patch" for this, which both should be used.
Please carry on reading there by yourself.
TL;DR: RPM scriptlets provide all you are asking for and more.
There is an intermediate layer of complexity between a RPM
which offer a lot of features (full feature) at the cost of having to deal with its specific syntax (which is quite complex because it should deal with all the dependencies of the all the packages in the repository and with the installed ones) and executing shell scripts during a Patch Manager
installation. Web Catalog
is not the problem because it has to deal with a compressed archive (e.g. pippo.tar.gz
) while the Patch Manager
have just to execute 4 simple operations as far as all four scripts files exist. There is a HUGE gap between applying a patch (diff -pruN
) and preparing a RPM
, in this HUGE gap, Patch Manager
shell scripting capability has its own place.
There will be no feature allowing to run random shell scripts as root in Patchmanager.
That would be wrong on so many counts it's not even funny.
Strange to ear because patch executes with root privilegs in order to apply .patch to system files.
Anyway take a look here to just to have a glimpse how tar (new enought version) and gz can do:
About reconfiguring SailFish OS at system level.
Patchmananger's principal purpose has been, is and will stay to alter proprietary text files, specifically the QML files which Lipstick, Silica and some SailfishOS applications (e.g., the settings app) are comprised of, because no elements from these SailfishOS components can be forked and redeployed.
Patchmanager may be used to alter any text file, but will not employ any specific provisions for other special text files (e.g., systemd units) than proprietary ones, because any software under a FLOSS license can be forked and redeployed as an RPM package.
DESCRIPTION
Reading the description of this patch, we clearly realise that adding shell script capabilies will bring PM2 to the next level. In order to achieve this there are some type of specific scripts to keep in consideration:
pre-install.sh
post-install.sh
pre-remove.sh
post-remove.sh
Which are the same types that are allowed into any kind of package (rpm, deb, etc.). Obviously, these scripts should be executed with
root
privileges and possibly in a decently set enviroment. Possibly a $PATCH_PATH or $PATCH_DIR (with or without the underscore) could be set in order to refer to folder in which the patch archive is extracted. In this way, more files can be added to be parsed by the scripts or copied into the system.ADDITIONAL INFORMATION
This feature can be implemented in two different ways:
In the last case, something like that:
One or another way is indifferent and It is a matter of taste. In .sh case the files do not need to be executable to run but just being interpretable. However, the .sh approach avoid to have a parser to split the .shell single file and moreover, it clears the possible misunderstanding about the chance that every single line will be executed by a different shell instance:
instead of
It is suggested to use /bin/ash as default interpreter which is enough powerful in terms of scripting even if does not implement the full set of bashism. This because the scripts relying on /bin/ash can run on /bin/bash as well but in some system /bin/bash could be optional.