Automatically remove relevant repo_depends entries for official packages

[yan12125]

Tested with the following cases

• cub
• mxnet-git (involved with split packages)
• lxqt-build-tools, libqtxdg-git (multiple packages)

A sample commit for the last test case can be found at https://github.com/yan12125/repo/commit/49ab72085b3a0c0c9827cff1889feefdb5d14708

Note that a new dependency python-ruamel-yaml is introduced in this pull request.

[yan12125]

Oh, issuebot should reject orphan requests with packages that are in repo_depends of other packages, too. Too lazy to finish them today.

[lilydjwg]

Oh, issuebot should reject orphan requests with packages that are in repo_depends of other packages, too.

Maybe mention maintainers in a comment whose repo_depends is going to break? What to do afterwards then? Do we check everyday if the packages could be removed?

[yan12125]

Maybe mention maintainers in a comment whose repo_depends is going to break? What to do afterwards then? Do we check everyday if the packages could be removed?

Here is my original plan: when the orphan request is created, listing packages that are used by other packages, and when ORPHANING_WAITING_TIME is due, simply skipping packages that are still used. Maybe maintainership is transferred during the period, or depending packages are also orphaned. If nothing happens, to-be-orphaned packages will still be maintained by the original maintainers. Another orphan request is needed if the dependency is resolved after ORPHANING_WAITING_TIME is due.

[lilydjwg]

to-be-orphaned packages will still be maintained by the original maintainers

I don't think this is a good idea. When a maintainer orphans packages, they mean to stopping maintaining them. No maintainer should be forced to maintain packages.

I think there are two ways:

1. Keep the orphaning packages but without maintaners. It'll break eventually and depending packages will break.
2. Remove the orphaning packages anyway. Depending packages will break.

When depending packages break, their maintainers are expected to fix them.

Given the same eventual outcome, I prefer 2 for simplicity. We notify depending-package maintainers in the orphaning issue so they can keep up.

[yan12125]

Remove the orphaning packages anyway. Depending packages will break.

If we go that way and https://github.com/archlinuxcn/repo/pull/1574 is merged, CI tests will be red for some time and everyone pushes to the repo during that period will receive mails about build failures. That sounds not good to me, either.

An extreme case is lib32-libmng. It is orphaned and then removed on May 20, 2019. After that date, lib32-qt4 is broken until lib32-libmng is re-added on Apr 10, 2020 [2].

No maintainer should be forced to maintain packages.

Indeed that makes more sense. How about transfer maintainership automatically? For example, if A is orphaned, and B and C repo_depends on A, then maintainers of A will become union of maintainers of B and C.

[1] https://github.com/archlinuxcn/repo/commit/dedbaecbc010aabfb94e4d9b94fb1f1d7f89d285 [2] https://github.com/archlinuxcn/repo/commit/8f535d9c8333ad2fb445b12eb8646f10a7be76c6

[lilydjwg]

Ah yes.

How about transfer maintainership automatically?

Maybe create a vote for this to collect options?

One option is to transfer, the other is to keep without maintainers. The former may make responsibility vague because of multiple non-cooperative maintainers. What issues may the latter have? If an orphaned package A caused B to fail, maintainers of B are expected to look into the issue and they may decide to take over A or drop B.

[yan12125]

What issues may the latter have?

I guess no. Nevertheless, it's still better to collect opinions from more package maintainers, so I created https://github.com/archlinuxcn/repo/issues/1676.

[yan12125]

This time I only tested the third case: lxqt-build-tools, libqtxdg-git (multiple packages)