Closed arozyev closed 9 months ago
Regarding the naming I'd vote for calling it --skip-not-applicable-patches
and to name functions and variables accordingly. The brief description could simply say 'Skip needed patches which do not apply without conflict.'. The man page should also tell that the option may be useful in non-interactive scenarios in order to apply at least as many needed patches as possible, but that the system stays vulnerable if patches were skipped. zypper patch-check
can be used at any time to check whether the system is safe.
Regarding the option definition the easiest IMO would be to add a bool _skipNotApplicablePathches = false;
to PatchCmd
and to define it similar to --with-update/_withUpdate
:
--- a/src/commands/patch.cc
+++ b/src/commands/patch.cc
@@ -46,6 +46,9 @@ zypp::ZyppFlags::CommandGroup PatchCmd::cmdOptions() const
return {
{
CommonFlags::updateStackOnlyFlag( that->_updateStackOnly),
+ { "skip-not-applicable-pathches", '\0', ZyppFlags::NoArgument, ZyppFlags::BoolType( &that->_skipNotApplicablePathches, ZyppFlags::StoreTrue, _skipNotApplicablePathches ),
+ _("Skip needed patches which do not apply without conflict.")
+ },
{ "with-update", '\0', ZyppFlags::NoArgument, ZyppFlags::BoolType( &that->_withUpdate, ZyppFlags::StoreTrue, _withUpdate ),
In case the option will actually be used in another command as well, it could be easily translated into a CommonFlag. OptionSets are actually intended for more complex groups of options which always belong together; like the download options.
AFAICS PatchCmd::execute
calls solve_and_commit
with a SolveAndCommitPolicy
object. So extending SolveAndCommitPolicy
to carry the PatchCmd::_skipNotApplicablePathches
value down to the conflict processing could be sufficient then.
Storing and remembering the value at global scope in Config.h
rather than locally to the command bears the risk, that it is not properly reset at the end of the command in zypper sh
.
In SolverRequester.h
it's probably an artefact?
this PR is a draft to consult if adding option is correct. We need to extend zypper with a feature to ignore patches that require manual resolutions from the user.
Brief test, log entry is generated based on the boolean flag set inside
PatchCmd::execute()
method1) Without --skip-manual-resolvable-patches
1) With --skip-manual-resolvable-patches