The automation from multiple application grows. For example: - updating metric and keys in the TPM after kernel update - removing very old kernels - report for sysadm there is currently no automatic way AFAIK. I request a feature, the package manager provides hooks for packages. Suggestion as example: /etc/${packagemanager}/*kernel*/10_update_tpm.sh /etc/${packagemanager}/modemmanager/10_send_sms_and_email.sh I see that regular expression is not the best to be handled from filesystem... /etc/packagemanager/any-label/configuration.conf the configuration may contain the regular expression for packages
Assignee: bugsquad => mageiatoolsCC: (none) => marja11, thierry.vignaud
Any comment ?
No comment ?
No comment…
rpm already has hooks. https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/ Duplicating that at the higher level of urpmi would require modifying not just urpmi, bug dnf too, and anything done there should also be handled when manually downloading a package and using rpm -i directly. The only benefit I see for urpmi/dnf hooks would be allowing rpm to be called multiple times, for example when force uninstalling a package with a broken uninstall scriptlet, in order to allow an update to then be installed cleanly.
CC: (none) => davidwhodgins
Many thanks Dave for showing interrest. I'm aware of the %post section in the rpm spec, but in my opinion we are mixing the scope. Rpm spec should only focus on the package itself, up to restarting some services. But nothing more. System administrators may want to have custom script execution for any package update. We can add to all spec a %post install section executing all scripts matching its name, but I believe it will be a dirty workarround.
I still think the appropriate place for such a feature would be in rpm itself, so that it doesn't matter which package manager (if any) is used to install an update. I can't think of many use cases for such a feature. Most cases where it might have been useful also have timing requirements, such as next login, next gui start, next boot, etc, so have other appropriate places, which vary depending on which desktop environment (if any) is being used. Justifying the work involved in changing both urpmi and dnf to handle such a feature would require clear examples which don't have other existing places that are more appropriate.