A successful scratch build of the F29 'fedpkg' package with this change (including this commit as a patch) can be viewed at: https://koji.fedoraproject.org/koji/taskinfo?taskID=30479497

See https://src.fedoraproject.org/fork/merlinm/rpms/fedpkg/c/babfc4bd83c707490d23dd4c335dfc30dff6e9a6?branch=retire_retire for the patched package that was used for the scratch build.

Why do you move retire to rpkg?

retire should work in fedpkg not rpkg. The only difference in your patch is the if-statement. It also works in fedpkg.

@cqi Sorry for the delay in responding. I moved the retire functionality to rpkg so it could also be used by rhpkg--Red Hat's internal utility that parallels Fedora's fedpkg--which is also based directly on rpkg.

@cqi Sorry for the delay in responding. I moved the retire functionality to rpkg so it could also be used by rhpkg--Red Hat's internal utility that parallels Fedora's fedpkg--which is also based directly on rpkg.

@merlinm, I'm wondering how will rhpkg use retire functionality?

@pbabinca, rhpkg will use the retire functionality exactly the same way fedpkg does--to mark obsolete package/modules as "dead".

And in case it isn't clear, by adding the retire code to rpkg (by https://pagure.io/rpkg/pull-request/387) and removing it from fedpkg (by this PR), fedpkg continues to have full retire functionality--it will just be inherited from rpkg. As already stated, this also allows rhpkg to automatically pick up the retire functionality from rpkg.

@merlinm, internally we make branches readonly with slightly different approach. And currently to make a package readonly or undo this readonly it requires release engineering privilegies.

Using same approach as Fedora - with dead package would be weaker. Anybody make dead package alive with just revert of last commit.

I'm not saying we cannot do that. Just that with the current implementation we would have two different approaches to retire packages which I don't really like.

@pbabinca I see where you're coming from now. Wouldn't the two approaches work together and compliment each other? A readonly branch doesn't really make it obvious to the developer that a package is retired, does it? However, it would be perfectly obvious if the dead package marker was put in place before making it readonly. There have also been some discussions about the MBS needing to take action when encountering retired modules--which is what prompted the rpkg/fedpkg change.

Making the branch read-only includes putting a file there with a reason why this is done. Only the file is not called dead.*, but READONLY, and the change can only be done by RCM.

@pbabinca @lsedlar Would it be acceptable to make revisions to rhpkg to restrict it to only be able to retire modules? That way, retired packages can continue to be handled in the same way they have been.

If that would be possible that sounds like a plan.

Btw. Lubomir is out until end of the month.

@pbabinca @lsedlar I have updated rpkg (https://pagure.io/rpkg/pull-request/387) to make package retirement a configurable option defaulting to False, and fedpkg has been updated (this PR) to enable that option. This allows rhpkg to inherit the desired module-only retirement functionality from rpkg without any code changes.

The approach as you describe it sounds good to me. I'll leave more comments on the rpkg PR.

Revised per the latest update to rpkg PR https://pagure.io/rpkg/pull-request/387 which now uses a configurable list of namespaces for which retirement is blocked--which includes 'rpms' by default. I also rebased my commits to the latest master branch.

At @onosek's request in https://pagure.io/rpkg/pull-request/387, I rebased this PR to the latest commit in master and squashed.

It looks fine. Thanks.