Use el8/9 epel qpid proton 0.37.0+

[jrafanie]

Undo #409 now that we're ready to use the upstream packages in el8 or el9 epel qpid proton 0.37.0+

To be merged with ManageIQ/manageiq#22271
Needed for ManageIQ/manageiq#22696

Followup: #560

[Fryguy]

We might need something on appliance upgrade as well, since these are in kickstart.

[jrafanie]

We might need something on appliance upgrade as well, since these are in kickstart.

Good point. I'm not sure how to do that. I will need to ask @bdunne. I assume these commands write values in the /etc/yum.repos.d directory but will need to followup on the upgrade for this.

EDIT: Added #560 to track the upgrade.

[agrare]

I'm working on getting the proper qpid-proton-c package installed,

I can disable the exclude by adding the following to the manageiq-gemset spec

%pre gemset
# Disable the qpid-proton exclude and use the standard EPEL package
dnf config-manager --setopt=epel.exclude= --save

But that leaves qpid-proton-c as 0.30.0-2.el8 after the rpm install.

If I add a version requirement Requires: qpid-proton-c >= 0.37.0 then the dnf install fails because the manageiq-gemset%pre hasn't run yet.

If I manually run dnf config-manager --setopt=epel.exclude= --save then install the RPMs then the qpid-proton-c package is updated as expected

  Upgrading        : qpid-proton-c-0.37.0-1.el8.x86_64                                                                                     3/20 
  Running scriptlet: qpid-proton-c-0.37.0-1.el8.x86_64  

Obviously not ideal...

[Fryguy]

Is it possible to put the dnf config-manager --setopt=epel.exclude= --save in a package that would get installed first, or is there no guarantee to the order?

[agrare]

Package dependencies will guarantee the order but I think that DNF resolves the requirements before actually installing any package, but I can test it

[miq-bot]

Checked commit jrafanie@698465e with ruby 2.7.8, rubocop 1.56.3, haml-lint 0.51.0, and yamllint
0 files checked, 0 offenses detected
Everything looks fine. 👍

[Fryguy]

Is it possible to put the dnf config-manager --setopt=epel.exclude= --save in a package that would get installed first, or is there no guarantee to the order?

Package dependencies will guarantee the order but I think that DNF resolves the requirements before actually installing any package, but I can test it

This just got me thinking that it might be interesting to have an "installer" RPM. So you'd dnf upgrade the installer, then run the installer, which could run any "pre-install" steps, then it would run dnf upgrade on the rest. We were talking about having a script that the user could run beforehand, but this would simplify even that script step.

cc @bdunne

[jrafanie]

This just got me thinking that it might be interesting to have an "installer" RPM. So you'd dnf upgrade the installer, then run the installer, which could run any "pre-install" steps, then it would run dnf upgrade on the rest. We were talking about having a script that the user could run beforehand, but this would simplify even that script step.

cc @bdunne

wouldn't you still have a dependency tree of

installer rpm
|
 \
  - manageiq-*
  |
  - manageiq-gemset
     \
      - qpid-proton-c >= 0.37.0

If manageiq* doesn't depend on the installer, you can upgrade the manageiq* rpms without the installer. I'm not sure how you'd force it to be in sync.

If you have the tree above, you can't resolve the qpid-proton-c dependency until you run the command to clear the dnf epel exclusion. I think it's a chicken and egg problem.

[Fryguy]

@jrafanie As discussed, no, the idea is the installer/upgrader rpm would be independent. Then any "special" pre-install stuff could be put in a script. In fact, since it's pre-install, we would also know what version we are coming from and can make different choices.

I will open a separate issue to discuss the details - this will be for radjabov anyway.