koji

#2614 CLI add-tag-inheritance --force returns error
Closed: Fixed by tkopecek. Opened by mfilip.

Closed: Fixed
Reopen Issue

Multiple same inheritances with different priority result to error which asks for using --force

koji add-tag-inheritance tag-0b7by tag-yhijy --priority=1
koji add-tag-inheritance tag-0b7by tag-yhijy --priority=2
You are attempting to add tag-yhijy as tag-0b7by\'s parent even though it already is tag-0b7by\'s parent.
Please use --force if this is what you really want to do.

But using force does not resolve the situation and results to another error.

koji add-tag-inheritance tag-0b7by tag-yhijy --priority=1
koji add-tag-inheritance tag-0b7by tag-yhijy --priority=2 --force
Changes should not contain duplicated parent_id(53)

We've to unite CLI command with hub behaviour. Hub call is forbiding this now, while CLI suggests --force to override it.

Metadata Update from @tkopecek:
- Custom field Size adjusted to None
- Issue set to the milestone: 1.25

PR #2704

PR #1434 broke this behaviour on hub side. It looks better to me to not allow it, but maybe there are some cases when it makes sense (e.g. first parent with some filter option, while second without).

Anyway, nobody complained for last two years that we've changed it this way and it can be workarounded by little bit more complicated inheritance tree.

So, I would hide --force option (SUPPRESS_HELP) and raise a deprecation warning in case it is used.

@mikem Do you agree?

The purpose of --force in this command is "adding a parent to a tag that already has that parent tag". The example Tomas gives above is the sort of case that I presumably had in mind way back when (this option has been there since at least the initial public release of Koji).

Inheriting from a tag multiple ways with different inheritance options is valid and the data model allows it. So I guess I don't agree here.

Looking at #1434 again (It doesn't look like I gave it a very deep review before), I think that the change is questionable and the one of the issues it addresses (#1435) is unclear. Rather than drop this longstanding option, we should fix the regression. I would like to see a clearer problem statement for #1435.

The inheritance traversal code on the hub specifically deals with redundancy during traversal. Even if tags are not allowed to have the same parent twice, this can still occur if a tag inherits from two tags that share a parent. The code addresses this. It ignores duplicates, but allows a rescan if the inheritance options are different.

I suppose that it might make sense to rename the option to something more accurate. This is more like disabling one specific lint check.

@mikem do you have a name for option instead of --force?

And please, can you create second separate issue for regression and there will be described your idea?

@jcupova this is arguably the issue that tracks the regression

pr #1434 was merged 2 years ago and has been in Koji since 1.18.0. It refers to two issues -- #1433 and #1435. The former is a pretty straightforward typo. The latter seems to be an invalid issue stemming from a misunderstanding of the inheritance data model. However, the content of #1435 is terse and I want to make sure there isn't a real underlying issue there. It's not quite clear to me what the complaint there is.

It's possible that there is some issue with deleting inheritance links when a parent appears twice that this PR was trying fix.
Edited by mikem

as far as renaming the option, I think it's a fairly specific and probably rare case. Perhaps --allow-duplicate.

If we did rename the option, we'd still want to preserve the existing usage as a hidden alias.
Edited by mikem

@julian8628 can you clarify the root issue that led you to file #1435?

@mikem
The problems I want to fix are:

1. The consistance issue described in #1435

If duplicate parents are allowed, we are assuming that the changes were made by the order of the InheritenceData, but in the hub call setInheritanceData, it is not true.

Like the example in #1435:

$ koji call getInheritanceData 48
[{'child_id': 48,
  'intransitive': False,
  'maxdepth': None,
  'name': 'test-parent-tag',
  'noconfig': False,
  'parent_id': 350,
  'pkg_filter': '',
  'priority': 10}]
$ koji call setInheritanceData 48 --kwargs "{'data':[{'parent_id': 350, 'delete link': True, 'priority': 10, 'maxdepth': None, 'intransitive': False, 'noconfig': False, 'pkg_filter': ''},{'parent_id': 350, 'priority': 10, 'maxdepth': None, 'intransitive': False, 'noconfig': False, 'pkg_filter': ''}]}"
None
$ koji call getInheritanceData 48
[]

The first item "delete link" is to delete 350 parent link, then the second one is going to add it back. But because the fields of both items are totally the same, the latter one is not set to the data (https://pagure.io/koji/blob/master/f/hub/kojihub.py#_719).

2. Complexity introduced by multiple parents in changes

If the changes list contains a set of operations against the same parent link, It could be easily replaced with a single link item. I didn't think this tolerance is necessary, but maybe I missed some situations.
Edited by julian8628

anyway, the issue of #1435 could be fixed by cleaning the data of "delete link" item

PR #2782

Metadata Update from @julian8628:
- Issue tagged with: testing-ready

Metadata Update from @mfilip:
- Issue tagged with: testing-done

Commit 5c40091b fixes this issue

Commit 8845b9eb fixes this issue

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/2614

Please continue any further discussion there.
Metadata
None

testing-done testing-ready

None
None
Low
None
Related Pull Requests
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.