Three new hooks added:
PLUGINHOOK_SCRIPTLET_PRE_FUNC
Called before scriptlet execution
PLUGINHOOK_SCRIPTLET_FORK_POST_FUNC
Called after fork() but before scriptlet execution
PLUGINHOOK_SCRIPTLET_POST_FUNC
Called after scriptlet execution
Currently pre and post hooks are called for externals and internal lua scripts.
post hook is called even if scriptlet execution has failed and
the return code is given as an argument.
fork_post hook is only called for external scriptlets,
because for internal scriptlets no fork() is currently performed.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Two new hooks added:
PLUGINHOOK_SCRIPT_PRE_FUNC
Called before script execution
PLUGINHOOK_SCRIPT_POST_FUNC
Called after script execution
Both hooks are called for externals and internal lua scripts.
POST hook is called even if script execution has failed and
the return code is given as an argument.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
This change adds a new type of the rpm plugin, called transaction plugin
and a set of initial hooks for this plugin. The hooks are:
PLUGINHOOK_TSM_PRE
Pre-transaction hook that is called before an rpm transaction begins
PLUGINHOOK_TSM_POST
Post-transaction hook that is called after an rpm transaction ends
PLUGINHOOK_PSM_PRE
Pre-transaction-element hook that is called before an rpm
transaction-element is processed
PLUGINHOOK_PSM_POST
Post-transaction-element hook that is called after an rpm
transaction-element is processed
PLUGINHOOK_SCRIPT_SETUP
Per-script hook that is called once for each rpm mainainers script
that is present in the package
Each hook is called for every plugin that have this hook registered.
The avaliable transaction plugins can be specified in macros.in via
transaction_plugins element.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- Currently doesn't make any difference but since we actually
have a flags member in the struct, might as well use it. Also
we'll shortly be needing these during the actual execution too.
- No functional changes (and this is still internal-only API),
just making more obvious what they are and clearing the
RPMSCRIPT_FOO namespace for possible future use for the scriptlet
types themselves.
- Add accessor for fetching the script tag, the final piece that
psm needs (and will continue to do so) from script internals.
This allows the script type to become opaque for real.
- Bury rpmScriptNew() into being internal helper in rpmscript -
triggers and other scripts differ quite a bit in how their data
is laid out in the header, especially args need "special attention".
- Besides cleaning up things in the psm side, this technically makes
trigger scripts runnable without having a header at hand. Of course
currently trigger scripts are currently created and destroyed
on the spot from headers so this is of academic interest...
- Add a lower level script creation function to deal with the
body expansions and such, use it for triggers as well.
- This is still fairly ugly but its something that can be reasonably
backported to 4.9.x which needs this too, as currently triggers
are forgetting to set script->descr, causing "(null) failure" messages
on glibc and on others, in would just crash on trigger failure
and/or in debug verbosity level.
- We have no need for anything fancier, this makes 80% of the
overly complex & subtle semi-threaded and in places just broken
code in rpmsq.[ch] unused and unnecessary.
- rpmsqFork() behaves like regular fork() in this regard so this
just makes the code more obvious and eliminates an set-but-unused
warning while at it.
- If the write fails scripts are likely to fail anyway, but executing
partial scriptlets (unlikely as that might be) could have funny
side-effects besides just failing.
- Also cleans up runExtScript() a little bit by moving the
tmp file creation to a separate function.
- Bail out early and complain if current directory can't be open()'ed,
as we'll need it for reliable cwd restoration after running Lua
scripts.
- Technically we'd only need open(".") succeeding for chroot operations
and running Lua-scripts, but there's no easy way to determine whether
a transaction will run Lua-scripts. They could be in-db triggers
which will only be evaluated in the middle of transaction, better
to fail early for consistent behavior.
- For rpm itself forging global umask on init is kinda convenient, but can
be troublesome for API users. This is especially bad in python bindings
where just importing the rpm module silently changes process umask with
no good reason.
- Instead of global setting on init, only change the umask to 022 default
for the duration of rpmtsRun() where it's necessary for consistent
transaction results on implicitly created directories and files created
by scriptlets. This way we dont affect callers and provide better
"protection" for ourselves too - we don't know if API users change
umask again behind our back if we just set it on initialization.
- To make matters more fun, Lua scripts can change our umask. Save
and restore umask when running Lua scriptlets.
- pass scriptFd and selinux enabled status as arguments from psm level
- selinux status could be queried directly with is_selinux_enabled()
but that's a fairly expensive call which does all sorts of funny
things and probably doesn't work at all in the average chroot
- Lua-scripts dont currently honor scriptFd and have no use for selinux
but pass the info there too as an early step towards supporting
scriptFd with Lua
- makes rpmScriptRun() even more of an argument monster, some of this
should probably go into rpmScript struct...
- switch root if necessary on entry and exit to psm already, nothing
inside the psm needs access to outside chroot
- eliminate chroot handling from scriptlet machinery, dealing with
chroot is a job for higher levels
- Lua scriptlets can change our cwd, always ensure we return to previous
cwd after executing by saving and restoring the cwd
- Add per-scriptlet type flag tags to control special behavior.
- Add rpmlib dependency on scriptlet expansion - if a package relies
on scriptlet expansion it cannot be correctly installed with
a version of rpm that doesn't support it.
- Expansion is always an opt-in behavior, enabled with -q and/or -e argument
in spec. We can't just blindly expand even macros as there's no telling
%{} constructs might mean in whatever language is used for the script.
- Queryformat expansion requires great care with strange and ugly escapes
when writing scriptlets, but OTOH it permits access arbitrary header
data at runtime, which has previously been completely impossible.
- The handling of these expansions needs unifying for all scriptlet types,
the trigger scriptlet handling is uuugly. Macro expansion could be
transparently done from rpmScriptRun(), but because of their similar
syntax, macro expansion needs to happen before query format expansion,
and we dont have the header available in rpmScriptrun()
- Split the low-level scriptlet machinery out of psm
- New struct to hold the necessary information about scriptlets so
we can execute them without having a header at hand.
- Trigger handling is hackish and needs more love...
Elena Reshetova