It shouldn't be a part of normal workflow as API help notes: "Really this shouldn't be used except in special cases. Most of the time you really want to use the block or unblock functions". Is there some specific case which would benefit from this?

@tkopecek aha, I did not notice that… Probably documentation could be expanded why it should not be used? I mean, remove-pkg is considered bad because packages might be tagged already and it would do something really weird… but remove-group-pkg just changes comps.xml… or does it do something more?

Basically, inheritance could be the problem here. Tags a -> b -> c, package is added to a, blocked in b and unblocked in c. It is a normal practice but in the moment when package will be removed from b completely instead of just being blocked, c's unblock will do nothing and package will be missing there with "correct" record of being unblocked in c. It would introduce a weird workflow - unblock (non-existent) package and add it as a new one to c. So, it could confuse things a bit.

So, it could confuse things a bit.

Would not it make sense to handle such cases and simply reject command? Aka if there is some tag inherited, it will simply show such explanation and don't do anything unless some kind of --force is specified?

@mikem ^ makes sense to me. Any other concerns about using that call?

I guess same approach could be used even with other commands like remove-pkg, if no packages with such name are tagged, no inherited stuff has same packages it could work or otherwise show an error.

I do not think that we can programmatically catch all the cases where this shouldn't be run. The problem is essentially that most admins do not understand the subtlety of how the different components of comps are inherited piecemeal, the difference between blocking and removing, and the potential impact of the change when inheritance is involved.

The call is exposed via the api and can be accessed with a call command from the cli. Anyone expert enough to understand when this call is needed ought to be expert enough to run:

koji call groupPackageListRemove mytag mygroup mypkg

I would say that the first problem here is documentation. We should probably address that before thinking about adding a cli wrapper for this call.

Basically, inheritance could be the problem here. Tags a -> b -> c, package is added to a, blocked in b and unblocked in c. It is a normal practice but in the moment when package will be removed from b completely instead of just being blocked, c's unblock will do nothing and package will be missing there with "correct" record of being unblocked in c. It would introduce a weird workflow - unblock (non-existent) package and add it as a new one to c. So, it could confuse things a bit.

The more practical usability issue here is that users often do not realize where the entry is coming from in the inheritance, or what remove is actually doing. Here is a typical scenario:

• user sees that package X is showing up in comps for tag A
• user wants that package entry removed from tag A
• user calls groupPackageListRemove A mygroup X
• user gets an error, because the group packagelist entry is inherited from elsewhere and not in A

At this point, the user may either decide that Koji is broken, or dig in and realize that the group packagelist entry is actually inherited from tag B. In that case, they might proceed to:

• user calls groupPackageListRemove B mygroup X
• call succeeds
• however, tags C, D, and E also inherit from tag B, and the group packagelist entry was actually desired there

This is why the docstring says that blocking is preferred. It ensures that the entry will stop appearing in the tag that is specified.