• Karel Koci's avatar
    lib: move prerm to be run before postinst in transaction · 0ecb39fc
    Karel Koci authored
    This moves execution of prerm script from pkg_scripts step to pkg_move
    step. This effectivelly means that prerm and preinst scripts are run in
    plan order at the same time. This solves problems where prerm disables
    service or in general does operation which revers one done previous
    preinst.
    
    There are two consideration required. This code defines content of
    journal. The difference is that instead of editing all_configs table in
    pkg_scripts we generate it in its fullest in pkg_move. That is all right
    and fully compatible. The more problematic case is when we update from
    previous version of updater and there is journal stuck with completed
    pkg_move step but not yet completed pkg_scripts step. The result is that
    in such case prerm scripts are not run and packages are not in reality
    removed (removed from state). The real removal happens with next updater
    execution. So this is self healing problem that happens only with small
    probability.
    
    This also does one degradation in behavior. Previously we were ignoring
    removal operation for packages that were intended to be installed. In
    that case we just skipped remove section. The problem is that pkg_move
    does not have to_install argument and that makes it impossible to check
    if operation tries to remove package that is installed by some other
    one. The effect of such operation in this new implementation is that we
    would run in such case prerm script and removed given package info from
    status while preserved its files in system. That is worst case scenario.
    Other case where install request comes after remove request returns
    given info to state and runs preinst. That effectively just causes us to
    run both prerm and preinst where it should have been reinstall. That
    effectively should not cause anything bad.
    The real reason why we do not care too much is that only case when
    something like that happens is when pkgtransaction is used. pkgupdate
    never generates two operations for same package. Because pkgtransaction
    is dangerous tool in general I don't see it as huge problem.
    Other option is to pass to_install table to pkg_move as well but we
    would have to take care of situation where this field is not part of
    journal.
    0ecb39fc
Name
Last commit
Last update
..
data Loading commit data...
lunit-launch Loading commit data...
membench Loading commit data...
system Loading commit data...
usign @ 3e6648b1 Loading commit data...
Makefile Loading commit data...
Makefile.dir Loading commit data...
backend.lua Loading commit data...
cleanup.lua Loading commit data...
coverage.lua Loading commit data...
ctest.c Loading commit data...
ctest.h Loading commit data...
download.c Loading commit data...
events.c Loading commit data...
events.lua Loading commit data...
interpreter.c Loading commit data...
interpreter.lua Loading commit data...
journal.lua Loading commit data...
locks.c Loading commit data...
lua_coverage2info.pl Loading commit data...
luacheck.config Loading commit data...
multiwrite.c Loading commit data...
openssl_purity.mk Loading commit data...
picosat.lua Loading commit data...
planner.lua Loading commit data...
postprocess.lua Loading commit data...
requests.lua Loading commit data...
sandbox.lua Loading commit data...
subprocess.c Loading commit data...
subprocess.lua Loading commit data...
syscnf.c Loading commit data...
syscnf.lua Loading commit data...
test_data.c Loading commit data...
test_data.h Loading commit data...
transaction.lua Loading commit data...
updater.lua Loading commit data...
uri.c Loading commit data...
uri.lua Loading commit data...
util.c Loading commit data...
utils.lua Loading commit data...