Adam Williamson

> Looks good to me. It means that `base.resolve()` will be able to raise also `dnf.exceptions.MarkingErrors`, right? Anaconda will need to add an exception handler for that, but that should...

hmm, actually, there's still an issue there :\ `_finalize_comps_trans` is the first thing `resolve()` does, so if we raise an exception there, we won't do the rest of `resolve()`, and...

Well, I guess I looked for the error that's most similar to the existing warning, which is why I went with a 'missing package'-type error. We could make it any...

ah, hmm. the integration tests point up an interesting problem: this patch makes it fatal if you exclude a package from a group install. e.g. with this PR applied: [adamw@toolbox...

Thinking about some of the test issues and some of the feedback I've got on this, I'm kinda coming round to the idea that maybe this shouldn't be fatal for...

Well, I couldn't sleep on it, so I did a very rough version of a possible approach. This - letting callers pass in a mutable object for the function to...

> Thank you very much for the change proposal. with the proposal there are several questions that must be answered. > > 1. Is it a really good time and...

I guess my take on it is a question: why would a CLI user ever want this behaviour to be strict? If they want to not install when a group...

So a slight twist on the current proposal would be to do this instead: def resolve(self, allow_erasing=False, missing_raise=False): and then if `missing_raise` was set `True`, raise an exception if any...

> Anyway I have a great news. The functionality is nearly implemented in DNF5. DNF5 provides such an information about problems, hints during resolve() of requested operation reports in structure....