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
to comment on this ticket.