I'm not sure, that it is the way to go. You need to modify parent tag to explicitly allow debuginfo. It is ok, bigger problem is un/blocking which needs valid policy for this. I've sent extra to policy, so it can check, that it is sidetag, but it doesn't look neither easy, neither safe.

@mikem ?

Why do we want to have separate API call to emulate existing block-pkg/unblock-pkg?

Yep, it is ugly. I think that we can completely move this out and use normal commands, if we send more information to policy. (it is not the case for debuginfo)

For un/block I've no ability to compare, that calling user is sidetag owner. Not sure, how to easily workaround this than to have separate call.

I've removed those lines and instead created plugin-specific policy test. So, if using sidetag plugin, you now can use also is_sidetag_owner policy check, which would enabled you to create policy rules for un/blocking packages based on user/tag, etc. combinations (no needs to change hub in this way). Does it look better?

Like

match action block && tag f30-test-* && is_sidetag_owner :: allow

Would be also nice to have is_sidetag policy check, so that we can allow more things based on it.

Makes sense, added.

can we reuse policy checks here? I mean this code is basically duplicating what's being checked in policy function

Can't say much for the code, but the example of policy makes sense to me and I'd like to see it in Fedora.

I'm not sure if it can handle (un)block-pkg/(un)tag-pkg/regen-repo. If so, then I am super-happy.

Oh, and also set rpm macro for the tag. like a rpm.dist

Why can't we allow setting RPM macro same way as edit-tag does?

It would mean allowing a user to set any 'extra' fields. I don't want people to mess with all the settings - I think it would limit expectations of what can come from sidetag. Even setting of random rpm macros seems to me as a dangerous thing.

Can we just have policy what kind of edits is person allowed to do?

Basically any kind of edits should be fine for side tags.

:thumbsup:
I'm thinking if it is worthy to have a common tag.extra test

Commit 64101176 fixes this pull-request