Reproducer:
sack = get a sack for fedora 26 repo somehow

brs=['perl', 'perl(AnyEvent)', 'perl(AnyEvent::Handle)', 'perl(AnyEvent::Socket)', 'perl(Authen::SASL)', 'perl(Data::Dumper)', 'perl(Digest::SHA)', 'perl(Encode)', 'perl(Exporter)', 'perl(ExtUtils::MakeMaker)', 'perl(IO::Handle)', 'perl(MIME::Base64)', 'perl(Net::LibIDN)', 'perl(Object::Event)', 'perl(Scalar::Util)', 'perl(Test::More)', 'perl(Time::Local)', 'perl(XML::Parser::Expat)', 'perl(XML::Twig)', 'perl(XML::Writer)', 'perl(base)', 'perl(constant)', 'perl(overload)', 'perl(strict)', 'perl(warnings)', 'perl-generators']

for i in range(100):
    goal = hawkey.Goal(sack)
    for br in brs:
        goal.install(provides=br)
    goal.run()
    goal.list_installs()


This finishes under 1 second with -6, but needs ~10 seconds with -6.2

Now it considers the obsoletes too, but could be made faster (by adding API for setting multiple provides?)

Could this be given more priority? I understand it's not important for regular users, but it causes production problems for koschei. Our repo and build processing now lags behind what happens in koji, resulting in poor user experience for our users (when they get a notification about a broken build they need to wait for the dependency difference report).
And I can imagine that releng/qa tools that bulk process packages might be affected too.

can you please include code snippet or link what are you doing in Koshei with Selector.set(provides=...)?

Do you need the selector to find the package obsoleting provide name or just any package providing given Provide?

(In reply to Honza Silhan from comment #4)
> can you please include code snippet or link what are you doing in Koshei
> with Selector.set(provides=...)?
>

Our code for handling selectors consist of helper functions which were taken directly from dnf code [1] (the reason for bundling the code is that koschei backend used to be deployed on RHEL, where dnf wasn't available at that time)

> Do you need the selector to find the package obsoleting provide name or just
> any package providing given Provide?

We need to simulate installation of package BuildRequires the same way as it happens in koji (mock). We need to do the same thing as dnf builddep would do. So the answer to your question depends on whether dnf builddep needs it (I don't know that at the moment).

[1] https://github.com/msimacek/koschei/blob/master/koschei/backend/depsolve.py#L28

Hmm, so you are basically duplicating DNF code which has significantly changed recently in DNF.

If you get dependencies just from spec file then it is still unnecessary complex (_nevra_to_selector, etc.). Can you please try:
```
q = hawkey.Query(sack).filter(provides=dep)
s = sltr.set(one_of=q)
```
instead of:
`s = sltr.set(provides=dep)`


and report whether this approach is faster?
(this is current approach in DNF BTW)

(In reply to Honza Silhan from comment #6)
> Hmm, so you are basically duplicating DNF code which has significantly
> changed recently in DNF.
> 
> If you get dependencies just from spec file then it is still unnecessary
> complex (_nevra_to_selector, etc.). Can you please try:
> ```
> q = hawkey.Query(sack).filter(provides=dep)
> s = sltr.set(one_of=q)
> ```
> instead of:
> `s = sltr.set(provides=dep)`
> 
> 
> and report whether this approach is faster?
> (this is current approach in DNF BTW)

There's no one_of argument in f25's hawkey. I tried doing goal.install(q.run()[0]), which takes ~4 seconds in my test. Which is an improvement from 10 s, but still regression from mere miliseconds.

I also tried using dnf's Subject.get_best_selector in rawhide and got the same ~ 4s.

We try to fix the problem by reverting patch that introduce handling obsoletes for provide transactions (https://github.com/rpm-software-management/libdnf/pull/275), but we cannot back port it to fedora25, because it will reintroduce bug about obsoletes.

The patch was released into rawhide in libdnf-0.8.1-1