chore: un-cliwrap and use dnf5 instead of rpm-ostree

[bsherman]

I've been tinkering with and testing dnf5 for a while.

Key items are:

• ensuring cliwrap is properly unwound (checked rpm-ostree Rust code)
• using normal (not wrapped) binaries, eg for dracut
• and the more obvious, replacing "rpm-ostree install" with "dnf5 install", etc
• also uses dnf copr plugin to manage COPRs

Note this does NOT switch to using dnf copr plugin for ublue-os/akmods COPR since doing so removes the RPM managed repo file. That repo file needs to be renamed in the ublue-os-akmods-addons package to match the COPR naming convention.

Relates: #1946

[m2Giles]

We also need to explicitly test on both F40 and F41. We were bitten pretty hard enabling bootc in F40 with bad ISOs.

Additionally, we need to make sure that bootc label is present on our images so that we can integrate with the rest of the bootc ecosystem (F41 is good already)

[tulilirockz]

+1 for F41, it is working perfectly fine indeed

[tulilirockz]

Just realized that this will let us use https://github.com/osbuild/bootc-image-builder/ for the ISOs

[bsherman]

I just force pushed an update, and some keen observers may note that I ask people NOT to force-push their PRs... this is true, but in this case there were no comments/requests for changes on any files, so no context was lost.

[bsherman]

One known problem with this...

dnf5 doesn't currently return a failing exit code when a transaction fails. This means it's possible to have failed dnf operations but not fail the build...

This is... undesirable.

I think we need to decide:

1. do we want this now and deal with this risk
   -OR-
2. do we wait and see if dnf5 addresses this issue before we get forced to use it as rpm-ostree deprecates functionality in favor of dnf5?

[castrojo]

We can just keep this open right? Is there an open upstream issue we can track?

[bsherman]

We can just keep this open right? Is there an open upstream issue we can track?

I have found a few possible issues in the dnf tracker, but I haven't nailed down the exact problem either, so I'm not sure which to track, if any truly relate.

[m2Giles]

I think we hold off while we sort out which issues to track.

I've seen some of the issues with dnf5 working with fedora 41 containers and it's very bizarre to get an error message with a 0 exit code.

[noelmiller]

We can just keep this open right? Is there an open upstream issue we can track?

I have found a few possible issues in the dnf tracker, but I haven't nailed down the exact problem either, so I'm not sure which to track, if any truly relate.

@bsherman should we open an issue of our own for this in the DNF bug tracker? This would be a pretty serious bug that the DNF team and image mode for RHEL team would want to address.

Is there any way we can force a DNF command to fail in order to replicate it? Like an intentionally bad mirror or something as a test?

[tulilirockz]

ublue-os/bazzite#1905 (comment)

[bsherman]

We can just keep this open right? Is there an open upstream issue we can track?

I have found a few possible issues in the dnf tracker, but I haven't nailed down the exact problem either, so I'm not sure which to track, if any truly relate.

Possibly upstream issues I've found:

• Unify errors and exit codes of query commands rpm-software-management/dnf5#1075
• dnf5 update dnf has different behavior than dnf4 when the package is already updated rpm-software-management/dnf5#1862
• "dnf5 download" doesn't fetch packages specified by a URL rpm-software-management/dnf5#1726