Learn more about these different git repos.
Other Git URLs
Currently, I use the releng's find_unblocked_orphans.py script to generate the orphan packages report and i use this report to post an e-mail to devel(-announce) and all the affected maintainers, usually on Mondays.
Problem: The procedure ignores modular content entirely.
Why is that a problem? There are several sub-problems actually:
1. When a non-modular package depends on modular package and another non-modular package providing the same name/provide is orphaned, the report wrongly reports the package as endangered.
Example: Non-modular llamaherd depends on scala on runtime, hence uses the modular version of scala*, because scala has a default modular stream. Non-modular scala gets orphaned. The llamaherd is bogusly being spammed every week about this despite the fact it is no-issue to them. Possible outcomes: Maintainer learns to ignore this, possibly ignoring a real problem later as well. Maintainer panics and unorphans non-modular scala for no good reason. Maintainer panics and retires llamaherd for no good reason.
* Obviously, I have no idea whether a runtime dependency on scala that also isn't a buildtime dependency even make sense. Consider it just an example please. I've used an artificial package as a dependent, but a real package as the dependency, in order to make the example more understandable.
2. When a modular package depends on non-modular package, the modular maintainer is not informed about an endangered dependency.
Example: Modular python-django buildrequires non-modular python2. When python2 is orphaned, the modular maintainer is not notified of this (unless they maintain non-modular packages also affected by this, and even then they might not realize it also affects their module). Possible outcomes: The python-django modular package gets non-installable.
3. When a module is orphaned and either modular or non-modular packages depend on packages from it, their maintainers are not informed about an endangered dependency.
Example: Maintainer of modular python-avocado orphans the package and the module. No maintainers of either non-modular or modular packages that (Build)Require avocado are notified about this. Possible outcomes: Packages/modules depending on python-avocado get non-installable or fail to build from source.
(There are possibly more combinations of the problem.)
Solution: Adapt the reporting to take in mind modular packages. I don't even know how to repoquery them, so I am not volunteering to solve this problem. However, I would provide much insight, testing and feedback about this to the person who would do that.
Metadata Update from @psabata: - Issue assigned to psabata
@psabata Hello. Any update on this?
Pass --setopt '*.module_hotfixes=true' option to your DNF repoquery. That will involve all modular packages into the query. Once you identify an endangered package, use "dnf module provides ENDAGERED_PACKAGE" to obtain the module identifier.
But this approach will miss build-only packages and modules which are not in any YUM repository. You would need #166 first. On the other hand with #166, those modular build-only packages would contaminate your repoquery for non-modular packages.
The issue with with your script is that it assumes only one build root. That's not valid assumption anymore. Each module has its own buildroot. Your script would have to be run separately for non-modular Fedora and for each module taking modular dependencies into account.
Login to comment on this ticket.