Load build dependencies into the database

[irushchyshyn]

• On the package page, categorize dependencies into build time and run time
  

• Add relationships for build and run time dependencies separately:
  package.run_time_requirements, and package.build_time_requirements

So far build dependencies are only being shown on the package page left panel in Dependent packages and Dependency tree to showcase. They can also be displayed in the Dependencies sections, on Groups page etc. Also only run time dependencies are so far favored when deciding which packages are Blocked or when building a dependency graph.

Scope of #382

[irushchyshyn]

Note:
The numbers on the top progress bar have slightly changed in comparison to current state of portingdb:

The reason for that, is after we introduced collecting ambiguous requirements, we were adding some build only ambiguous requirements to the package dependencies (which is a bug). Therefore e.g. koji in protingdb depends on python-spinx, however it is a build time dependency only. I have fixed this in this PR, thus the inconsistencies.

[encukou]

This conflicts with #383 so I'll hold off the review, but I can comment on your comments:

So far build dependencies are only being shown on the package page left panel in Dependent packages and Dependency tree to showcase. They can also be displayed in the Dependencies sections, on Groups page etc.

It would be great to consider them in determining Group membership. And when that's done, show them in the Group view.
But that can be a separate commit.

The package page left panel is not immediately necessary, but you can add it for completeness' sake.

Also only run time dependencies are so far favored when deciding which packages are Blocked or when building a dependency graph.

I think that's fine.

[encukou]

Looks good at first glance. I probably won't have time to review in the next few days, feel free to double-check and merge.
Or if you feel something needs extra scrutiny, please point it out.

[irushchyshyn]

I am not sure about a couple of things:

1. On the Group page we show all the packages needed for the group (no separation between build time and runtime deps). I did it because the dependency lists get too long and not clear, if I do build time + run time categories as on the Package page. Is it ok like this, or do we need to add categories for some special use cases?

2. Do we need to track packages that build require Python, but do not build any RPMs that require Python? We currently do not. We only track build requirements of packages, which already existed in portingdb.

3. More general question and probably not much related to this PR.
   Python 2 leaf packages are currently determined while running the dnf Py3Query (not the way we determine e.g blocked packages). This is mainly due to 2 reasons:

   • we save SRPM to SRPM deps into database (not RPM to RPM, or SRPM to RPM);
   • we do not save non-Python (non in portingdb) dependencies at all (except for a couple of ambiguous ones).
     So, I am not sure if it is fine like that, or do I have to think about storing dependencies differently?

[encukou]

On the Group page we show all the packages needed for the group (no separation between build time and runtime deps). I did it because the dependency lists get too long and not clear, if I do build time + run time categories as on the Package page. Is it ok like this, or do we need to add categories for some special use cases?

That should be fine. Or we can tweak the display in the future.

Do we need to track packages that build require Python, but do not build any RPMs that require Python? We currently do not. We only track build requirements of packages, which already existed in portingdb.

If we start tracking these, I guess they'd just have an empty list of RPMS.
But I don't think it's necessary right now.

More general question and probably not much related to this PR.
Python 2 leaf packages are currently determined while running the dnf Py3Query (not the way we determine e.g blocked packages). This is mainly due to 2 reasons:

1. we save SRPM to SRPM deps into database (not RPM to RPM, or SRPM to RPM);
2. we do not save non-Python (non in portingdb) dependencies at all (except for a couple of ambiguous ones).

So, I am not sure if it is fine like that, or do I have to think about storing dependencies differently?

The main thing is that determining leaf packages takes the built requirements into account – they're leaves within Fedora, not within portingdb's set of tracked packages.
I wouldn't bother changing the mechanism until we have a plan of what to do with the new data.

[irushchyshyn]

@encukou thanks for clarifying everything.
I do not have anything else here, so I am merging this PR. If anything would seem wrong, feel free to file a bug.