Bug 1478569

Okay one thing I don't understand. You're installing fresh rhel-7.3 while having rhel-7 repo enabled or are you using subscription-manager --releasever 7.3?

Or are you trying to update 7.3 into 7.4 and hitting this issue?

If it's the first, then I believe you're unsupported from the described installation scenario. 

If you use CDN/RHSM and you force --releasever 7.3 for you shouldn't hit the issue.

On RHN there is just rhel-7 repo not rhel-7.4 or rhel-7.3. Therefore this is not doable.

Can you please double confirm?

Alright, here is the layout of this issue:

1. It is understood that people should /not/ be using incorrect releases of kickstarts versus other layered items (such as optional). [ This can be worked around from the RHSM side easily with standard release-versioning, but a little more difficult on the RHN side as the minor releases for some of these repos are only delivered as EUS content. ]

2. It is understood that optional is not a supported repository from Red Hat in any capacity other than delivery of bits.

3. Currently, this particular issue is not affecting many customers but we anticipate the case-load revolving around this issue to increase over time.

4. I understand this issue to be with the way the package is built:
  a. grub2-tools-efi obsoletes the other grub2 packages. This causes us to install it during kickstart even if we don't want it (and this is a package we are placing in a repo we don't even support!).
  b. If we change grub2-tools-efi to simply require a minimal version of grub2/grub2-tools, rather than obsoleting, we eliminate this problem.
  c. If there is ever a z-stream update to grub2 with the current configuration, kickstarting even RHEL 7.4 against the 7Server(7.4) tree of Optional would cause a failure due to the obsoletes.

I do not assume RCM action against this item.
I expect the packages to be built with our build/media creation processes in mind.

To me, this means that I should be able to build RHEL systems for certain against current release GA kickstart media with any other repositories active that are also for that minor release. -> Currently, this is a possibility, but it will not be if grub2 receive a single update via z-stream during RHEL 7.4's lifetime, or any other release if grub2-tools-efi also receives the version bump in a way that it still obsoletes the rest of grub2 items. The current obsoletes line is just for /any/ version less than current.

We are not asking to remove obsoletes from all of the grub2 packages, simply the one that is kept separate which is unlikely to be sought out in the first place.

Created attachment 1335360 [details]
Work around issues with cross-versioned repos.

> 4. I understand this issue to be with the way the package is built:

It isn't.  It's an issue is with mixing and matching a 7.x repo and a 7.x+1 optional repo (or any two releases), and it would be good to stop claiming otherwise.

The way these repos are being used is absolutely not tenable, and is guaranteed to cause more problems in the future, with any number of packages.

>   b. If we change grub2-tools-efi to simply require a minimal version of
> grub2/grub2-tools, rather than obsoleting, we eliminate this problem.

I think it has to be /as well as obsoleting/, but AFAICS having both will work around your problem as well as leaving the reasons for obsoletes addressed.

>  c. If there is ever a z-stream update to grub2 with the current
> configuration, kickstarting even RHEL 7.4 against the 7Server(7.4) tree of
> Optional would cause a failure due to the obsoletes.

Yes, setting up half of one build and half of the other is still a bad idea, even during initial installation.

> I do not assume RCM action against this item.
> I expect the packages to be built with our build/media creation processes
> in mind.

This is the bigger issue - mixing and matching repos in this way is inherently unreasonable.  It will lead to problems, because rpm packages are not built in a way that expects you to mix subpackages from one version with subpackages from another, and our repos were not designed in a way that actually supports this, either in general or these specific repos.

What you're asking for us to do in the packaging here is a (reasonable) hack around the fact that the repos are being used in a way that's very likely to cause problems in general.  That this time it's caused a problem hits the critical path is unfortunate, but it's not the bigger issue here.

I'm willing to do this (though I'll need some more ACKs...), but let's recognize it for what it is instead of trying to claim that it's more than a work-around for using the repos in a way that makes no sense at all.

Attached is my current patch; please review.

Created attachment 1335438 [details]
Work around issues with cross-versioned repos (v2 - 0.65%{?dist}.1 instead of 0.66%{?dist})

Created attachment 1335576 [details]
Just get rid of the whole issue.