-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strict config option deprecation #316
Conversation
This is the first step to deprecate and stop using `strict` config option. The problem with strict is that it has two meanings. If set to false, it does: 1. allow to skip packages that are not available in repositories (for install command) 2. allow solver to resolve depsolve problems by skipping packages that are causing these problems After the change the functionality of `strict` option will be implemented using two options - `skip_broken` and `skip_unavailable`.
In case the value of `strict` has been explicitely set, use it's negated value as the new defalt value for `skip_broken` and `skip_unavailable` options.
Now that `--skip-broken` does not set `strict` (which did both skip_broken and skip_unavailable) config option, but only `skip_broken` we need a way how to set also `skip_unavailable`.
The failing CI test is expected - it uses |
Now this option is one of the global options so we do not need to define it locally.
@@ -496,10 +496,16 @@ GoalProblem Goal::Impl::add_group_specs_to_goal(base::Transaction & transaction) | |||
std::vector<std::tuple<std::string, transaction::TransactionItemReason, comps::GroupQuery, GoalJobSettings>> | |||
groups_remove, groups_install; | |||
for (auto & [action, reason, spec, settings] : group_specs) { | |||
bool strict = settings.resolve_strict(cfg_main); | |||
bool skip_unavailable = settings.resolve_skip_unavailable(cfg_main); | |||
if (action != GoalAction::INSTALL && action != GoalAction::REMOVE) { | |||
transaction.p_impl->add_resolve_log( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because calls of add_resolve_logs() uses a different value for the last bool argument (skip_broken, skip_unavailable, ...) - I would recommend to add a description to that private method and what about to not call the argument as strict
. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only meaning of this argument is to distinguish whether the error
or warning
level is gonna be logged.
So I was thinking that strict
in this case kind of make sense. How about calling it is_error
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about to use: logger::Level instead? It will be mor generic and it will state what it does.
enum class Level : unsigned int { CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG, TRACE };
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. Although bool
argument was easier to use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added a commit changing the bool strict
argument of logging functions to libdnf::Logger::Level log_level
.
dnf5/main.cpp
Outdated
skip_broken->set_const_value("false"); | ||
skip_broken->link_value(&config.strict()); | ||
skip_broken->set_const_value("true"); | ||
skip_broken->link_value(&config.skip_broken()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that description of both option is on incorrect place. Those options are applicable only for a set of transaction commands - for upgrade does not make sense to allow skip-broken and so on. What about to use a similar approach like we have for security options --security
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point. I wasn't completely sure about making them global options. I'll move them to specific commands.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change (move from global options to specific commands) was a bit bigger than expected. I added it as 3 new commits to this PR - basically to make reviewer's life easier (and my also :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to create an issue for dnf5 project. I am fine with not implementing what I suggested in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's already here.
These options can be useful also for dnf5 plugins.
Added SkipBrokenOption and SkipUnavailableOption shared options. Also libdnf::cli::session::BoolOption costructor has been extended by optional argument `linked_option` to enable direct linking of BoolOption to configuration option.
Instead of creating global options, use the shared variants only in commands where needed.
Logging functions (transaction.p_impl->report_not_found() and transaction.p_impl->add_resolve_log()) used bool parameter to distinguish at which level the message should be logged. This patch changes the parameter directly to libdnf::Logger::Level making the semantics of the attribute more clear.
LGTM |
The PR introduces new config options
skip_broken
- for solver to enable resolving problems by skipping problematic packagesskip_unavailable
- to not fail when requested package is not availableDeprecated
strict
option (if explicitely set) is used as a default value for these new options.Also all occurrences of
strict
usage in the codebase are replaced byskip_broken
/skip_unavailable
.Fixes #269