Found during the transaction survey that led to #189, #190 and #191. Filed for discussion rather than as a bug: the current behaviour may be intentional.
Current behaviour
mport_bundle_read_install_pkg commits the package row and all its asset rows, then runs do_post_install (post-exec assets, POST-INSTALL script, Lua post-install hook, package message) and only then marks the package clean via mark_complete (libmport/bundle_read_install_pkg.c, UPDATE packages SET status='clean').
If any post-install step fails, the package stays status='dirty' with every asset registered. The two sides of mport then disagree about it:
check_preconditions.c:263 counts only status='clean' packages when resolving dependencies, so dependents see the package as missing and install will try to fetch it again.mport delete, mport list and the file-conflict check see it as present, since they query by name.
Possible intent
The dirty status may be there deliberately so that a partially completed install keeps its asset rows, allowing a later delete (or an update's backup-bundle rollback) to remove the files it added. If so, that is worth a comment at the mark_complete call and a decision on how the dependency check should treat dirty packages.
Options
- Keep dirty as "installed but incomplete": let the dependency check accept dirty packages, or have
install re-run only the post-install steps for a dirty package.
- Treat a post-install failure as an install failure: roll the registry rows back and remove the extracted files, leaving nothing behind.
- Leave as is, but document the meaning of
dirty and surface it in mport list/mport info so users can see why a dependency is being re-fetched.
Related: remove_stale_os_release_copy and the --force reinstall path both use delete_primative, which handles dirty packages fine, so options 1 and 3 do not need changes there.
Found during the transaction survey that led to #189, #190 and #191. Filed for discussion rather than as a bug: the current behaviour may be intentional.
Current behaviour
mport_bundle_read_install_pkgcommits the package row and all its asset rows, then runsdo_post_install(post-exec assets,POST-INSTALLscript, Lua post-install hook, package message) and only then marks the packagecleanviamark_complete(libmport/bundle_read_install_pkg.c,UPDATE packages SET status='clean').If any post-install step fails, the package stays
status='dirty'with every asset registered. The two sides of mport then disagree about it:check_preconditions.c:263counts onlystatus='clean'packages when resolving dependencies, so dependents see the package as missing andinstallwill try to fetch it again.mport delete,mport listand the file-conflict check see it as present, since they query by name.Possible intent
The dirty status may be there deliberately so that a partially completed install keeps its asset rows, allowing a later
delete(or an update's backup-bundle rollback) to remove the files it added. If so, that is worth a comment at themark_completecall and a decision on how the dependency check should treat dirty packages.Options
installre-run only the post-install steps for a dirty package.dirtyand surface it inmport list/mport infoso users can see why a dependency is being re-fetched.Related:
remove_stale_os_release_copyand the--forcereinstall path both usedelete_primative, which handles dirty packages fine, so options 1 and 3 do not need changes there.