Packit/TMT: Exclude podman packages from podman-next for tests

[lsm5]

See individual commits.

Checklist

Ensure you have completed the following checklist for your pull request to be reviewed:

• Certify you wrote the patch or otherwise have the right to pass it on as an open-source patch by signing all
  commits. (git commit -s). (If needed, use git commit -s --amend). The author email must match
  the sign-off email address. See CONTRIBUTING.md
  for more information.
• Referenced issues using Fixes: #00000 in commit message (if applicable)
• Tests have been added/updated (or no tests are needed)
• Documentation has been updated (or no documentation changes are needed)
• All commits pass make validatepr (format/lint checks)
• Release note entered in the section below (or None if no user-facing changes)

Does this PR introduce a user-facing change?

None

[lsm5]

let me check if dnf exclusion can solve this issue for good.

[lsm5]

Alright, this is good to go. Podman is only installed from the packit copr in TMT envs, which is the one we want to test.

The cockpit tests never used the podman-next copr so there's no reason to keep it in the packit config.

@containers/podman-maintainers @martinpitt PTAL

[Luap99]

LGTM

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lsm5, Luap99

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Luap99,lsm5]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[martinpitt]

I don't like this TBH -- seems to be prone to installing podman without matching dependencies? Isn't it often the case that newer podman versions need a newer crun/selinux policy etc.?

Your cited TF run is weird indeed. The dnf update -y podman crun conmon criu call is meant to upgrade to newer dependencies from the -next copr. And e.g. crun is much newer, it has a "102:" epoch in COPR and no epoch in Fedora. I can debug this, but it's certainly meant to be used.

Or asked the other way around: Do you expect -next to be tested as a group and want to have non-released dependencies in podman? Or expect podman main to work on all released distros without newer deps?

[lsm5]

@martinpitt I have used the ridiculous Epoch number on most, if not all, podman-next packages, but builds for all other coprs (like Packit) should use the default distro Epoch.

To use podman-next deps, I found simply adding the repo to packit config didn't suffice. We also needed to bump their priority in the TF env like this . I didn't see any such step in cockpit-podman.fmf and the TF log did show the packit copr rpm being tested. So, the podman-next repo in the cockpit job felt like a NOOP. That's why the removal here.

Yes, ideally, everything on main should be tested with podman-next, so how about I reuse the same dnf priority modification block in cockpit-podman.fmf? LMK.

[timcoding1988]

LGTM