Extend Options with allow_erasing and allow_downgrade

[vaibhavdaren]

Some artifact testing scenarios require the package manager to take actions it
would otherwise refuse by default:

• Obsoletes conflicts: When a system package explicitly obsoletes the artifact
  under test, DNF blocks the install. allow_erasing (--allowerasing) permits
  DNF to remove the conflicting system package so the target artifact can be installed.
• Transitive downgrades: DNF5 refuses to downgrade a transitive dependency even
  when the requested artifact requires an older version. allow_downgrade
  (--allow-downgrade) unlocks this for DNF5 (DNF4 already permits it by default).

Both options extend the existing Options dataclass and are wired into the DNF
engine family. YumEngine raises a PrepareError when allow_erasing is requested
since yum has no equivalent flag.

[gemini-code-assist]

Code Review

This pull request adds allow_erasing and allow_downgrade options to the package manager. Raise a PrepareError if allow_erasing is requested under YumEngine, as yum does not support --allowerasing.

[LecrisUT]

The PR description is too literal and unusable as a commit description. Keep it simple to only the reason of the implementation, not the literal implementation

[LecrisUT]

I would need the test cases to figure out if we are blocked by this. I don't suspect allow_downgrading to be necessary since the downgrading across system update is a current issue in Fedora, i.e. I suspect the default is already to allow the downgrade.

allow_erasing is the more difficult case to think of the scenario. Can you elaborate on what the system and artifact repo look like and the packages interactions?

[vaibhavdaren]

Here is the breakdown for both flags and the specific package interactions that require them (these correspond to tests T8 and T9 in our validation matrix:

1. Why we need allow_downgrade (DNF5 only)

While DNF5 will automatically downgrade a package if you directly request an older NVRA that has a higher repo priority, it blocks the transaction if downgrading that package requires downgrading a transitive dependency.

The Scenario (Test T8):

• System state: Guest has foo-1.4 installed.
• Artifact repo: Contains foo-devel-1.1.
• Interaction: foo-devel-1.1 has a strict requirement: Requires: foo = 1.1.
• Result: If we run dnf5 install foo-devel-1.1, DNF5 will refuse to silently downgrade the already-installed foo-1.4 to satisfy foo-devel-1.1. It fails the transaction. Passing --allow-downgrade explicitly permits DNF5 to cascade the downgrade to the transitive dependency. (DNF4 does this automatically, which is why the engine routes this flag only to DNF5).

2. Why we need allow_erasing (DNF4 & DNF5)

The primary driver for --allowerasing is handling Obsoletes replacements. If the base system contains a next-generation package that explicitly obsoletes the package the artifact is trying to test, DNF will block the install rather than removing the installed system package.

The Scenario (Test T9):

• System state: Guest has foo-ng-1.4 installed. The spec file for foo-ng contains Provides: foo and Obsoletes: foo < 1.4.
• Artifact repo: Contains the older/original foo-1.1 (this is the artifact we must enforce and test).
• Interaction: We tell DNF to install foo-1.1. DNF sees a conflict because the system already has foo-ng which obsoletes it.
• Result: Without --allowerasing, DNF aborts. With --allowerasing, DNF is permitted to erase the conflicting foo-ng from the base image and cleanly install our target artifact foo-1.1.

[happz]

When support for this flag gets added to the emerge package manager, no-one will recall there's a list of package managers supporting it at this place. Good note, but better suited for the dnf package manager plugin.

[vaibhavdaren]

Moved the documentation to dnf in 4458573.