Augment repository files with default priority when missing

[vaibhavdaren]

1. User-provided repository files (via repository-file provider): These are treated as authoritative user input and installed verbatim. If the .repo file defines a priority, it is preserved; if not, no priority is added.

2. tmt-artifact-shared repository: This is an internally-managed repository where downloaded artifacts are aggregated. It has a higher priority (lower numeric value) to have precedence over system repositories.

[happz]

I'm not sure we should be touching repositories in this way, especially repositories supplied as repo files. If they do not have priority set, are we sure it's a mistake? And that 50 is the right value to set? It would make sense to allow user to specify a priority if they wished, e.g. by supporting something like provide: repository-url:https://.../foo.repo:priority=50, but forcing single priority (which users cannot change...) does not seem good to me.

What is the motivation behind the change and the actual values?

[vaibhavdaren]

Context: Assume package P1 exists in two repositories:
R1, which is a repository explicitly added via the artifact install plugin, and
R2, which is an existing system/base repository.
If R1’s repo file does not define a priority, DNF treats it as having the default priority 99, the same as R2. When running dnf install P1, DNF may then resolve P1 from R2 instead of R1, even though R1 was explicitly added for this operation.

Q1-> What should dnf resolve to R1 or R2. [We need to understand the default behaviour of DNF]
Q2-> Does this behaviour for dnf change over different os versions [ We need to alligin with the team so that dependency resolution is deterministic]

Expected / desired behavior
When a user adds a repository explicitly (R1), the intuitive expectation is that packages should be installed from that repository unless the user has clearly indicated otherwise. In the example above, that means P1 should come from R1, not R2, because the act of adding R1 signals intent to use it.

What we are trying to do
By assigning a non-default priority (e.g. 50) to the provided repository, we ensure that R1 is preferred over default system repositories (priority 99) during dependency resolution. This makes the behavior deterministic and avoids surprising outcomes where packages silently come from R2.

The exact value is not special; it simply needs to be better than the default, and this can later be extended to allow users to specify a custom priority if needed as you told.

[happz]

Context: Assume package P1 exists in two repositories: R1, which is a repository explicitly added via the artifact install plugin, and R2, which is an existing system/base repository. If R1’s repo file does not define a priority, DNF treats it as having the default priority 99, the same as R2. When running dnf install P1, DNF may then resolve P1 from R2 instead of R1, even though R1 was explicitly added for this operation.

Q1-> What should dnf resolve to R1 or R2. [We need to understand the default behaviour of DNF] Q2-> Does this behaviour for dnf change over different os versions [ We need to alligin with the team so that dependency resolution is deterministic]

Expected / desired behavior When a user adds a repository explicitly (R1), the intuitive expectation is that packages should be installed from that repository unless the user has clearly indicated otherwise. In the example above, that means P1 should come from R1, not R2, because the act of adding R1 signals intent to use it.

What we are trying to do By assigning a non-default priority (e.g. 50) to the provided repository, we ensure that R1 is preferred over default system repositories (priority 99) during dependency resolution. This makes the behavior deterministic and avoids surprising outcomes where packages silently come from R2.

The exact value is not special; it simply needs to be better than the default, and this can later be extended to allow users to specify a custom priority if needed as you told.

Not convinced it should be us who slaps a hardwired priority on user-provided repository file, sorry. Why can't we tell user "hey. your repo lacks priority, you're on your own - you want predictability? add priority key, FYI, system repos have 99, 50 would work well". User gives us a file and says "this I need to be added to the system", and we wouldn't do that, we add some modified version of it.

[vaibhavdaren]

Yes. that’s exactly the right consistency model, and I think we should make it explicit.

Proposed rule

repository-file provider

• We treat the repo file as authoritative user input
• We install it verbatim
• If it does not define priority, we do not add or infer one
• Should accept a priority-key or argument to get user-defined-priority.

repository-url provider

• Even though we are generating the repo file, the semantics still belong to the user
• Therefore:
  • If they do not, we generate the repo file with a default priority used for artifact installation

tmt-artifact-shared repository

• What priority should we give to the tmt-artifact-shared-repository , the repo where we keep the downloaded artifacts? -> We use the default priority set for artifact installation

[LecrisUT]

Minor suggestion, otherwise LGTM

[thrix]

@vaibhavdaren from the description:

The shared artifact repository doesn't take precedence over system repositories (typically priority 99)

I believe this is incorrect, it actually does. default priority is 99, 50 will cause higher prio.

[vaibhavdaren]

@vaibhavdaren from the description:

The shared artifact repository doesn't take precedence over system repositories (typically priority 99)

I believe this is incorrect, it actually does. default priority is 99, 50 will cause higher prio.

@thrix : Fixed the description.

[thrix]

The failed test is a flake