• Describe the issue
  @pbrobinson wants to push some updates to linux-firmware which rename the Intel wireless subpackages. This has a bit of a problematic interaction with comps.

The comps hardware-support group specifically lists several of the existing package names. When openQA tries to build a netinst or ostree installer image with the new updates, it fails, because dnf or anaconda or something doesn't like that it's trying to pull in packages that are now obsoleted:

Dependency check failed: 
 Problem 1: conflicting requests
  - package iwlegacy-firmware-20230625-151.fc39.noarch from advisory obsoletes iwl4965-firmware < 20230625-151.fc39 provided by iwl4965-firmware-20230515-150.fc39.noarch from rawhide
  - package iwlegacy-firmware-20230625-151.fc39.noarch from advisory obsoletes iwl4965-firmware < 20230625-151.fc39 provided by iwl4965-firmware-20230515-150.fc39.noarch from koji-rawhide
 Problem 2: conflicting requests
  - package iwlwifi-dvm-firmware-20230625-151.fc39.noarch from advisory obsoletes iwl6050-firmware < 20230625-151.fc39 provided by iwl6050-firmware-20230515-150.fc39.noarch from rawhide
  - package iwlwifi-dvm-firmware-20230625-151.fc39.noarch from advisory obsoletes iwl6050-firmware < 20230625-151.fc39 provided by iwl6050-firmware-20230515-150.fc39.noarch from koji-rawhide
 Problem 3: conflicting requests
  - package iwlwifi-mvm-firmware-20230625-151.fc39.noarch from advisory obsoletes iwlax2xx-firmware < 20230625-151.fc39 provided by iwlax2xx-firmware-20230515-150.fc39.noarch from rawhide
  - package iwlwifi-mvm-firmware-20230625-151.fc39.noarch from advisory obsoletes iwlax2xx-firmware < 20230625-151.fc39 provided by iwlax2xx-firmware-20230515-150.fc39.noarch from koji-rawhide
template command error in runtime-install.tmpl:
  run_pkg_transaction

Peter filed a comps PR which updates the comps entries in F37, F38 and Rawhide.

For Rawhide there is, I think, one awkward ordering issue. We want to merge the comps change and push the update stable. But the update can't pass tests until the comps change is merged...but if we merge the comps change, the next compose may fail because the update isn't stable and it winds up looking for packages that aren't there, so the updated comps data won't get published. It's kinda a catch-22. The best thing to do there might be to just waive the test failures, push the update stable, and merge the comps PR at the same time.

For F37 and F38 it's worse, because of how comps data updates work on stable releases. The comps data from the release repo is always there, it never goes away. So even if we merge the PR and do an update push, we wind up with a complicated state. I think if we do that, we might wind up with lorax/anaconda/whatever wanting to pull in all the packages - the old names listed in the release repo comps data, and the new names listed in the updates repo comps data. I'm not sure, but that's my best guess as to what will happen (if anyone knows better, please chip in).

So, I'm not actually sure if it's possible to really do this kind of rename for a stable release in such a way that we don't wind up with a problem in the comps data. @kevin , do you have any idea how to square this circle?

I did merge the comps PR for a few minutes, but I've now reverted it so we can think things through. As things stand, the updates will be blocked from going stable due to the tests failing, but the tests shouldn't fail for any other updates, so we can think this through carefully.

• When do you need this? (YYYY/MM/DD)
  No particular date, but the updates are blocked till we can work it out.

• If we cannot complete your request, what is the impact?
  The updates will be blocked so new firmware isn't available and the rename can't go through.