#8676 EPEL 7 - package versions out of sync between architectures
Closed: Fixed 4 years ago by kevin. Opened 4 years ago by ellert.

  • Describe the issue

The aarch64 architecture is not up to date w.r.t. the other architectures. This causes differences in how packages are built, and builds - even though they are successful - are rejected due to that noarch subpackages differ between architectures. See e.g.

https://apps.fedoraproject.org/koschei/package/root?collection=epel7
https://apps.fedoraproject.org/koschei/package/nordugrid-arc?collection=epel7

In one case above different versions of rpm (4.11.3-35.el7 vs 4.11.3-40.el7) result differences in autogenerated perl dependencies.

  • When do you need this? (YYYY/MM/DD)

As soon as possisble

  • When is this no longer needed or useful? (YYYY/MM/DD)

When RHEL 7 is EOL

  • If we cannot complete your request, what is the impact?

The affected noarch packages could possibly be converted to arch-dependent packages. But it would be inconsistent and waste disk space.


aarch64 is no longer in sync because RHEL did not build a RHEL-7.7 of it. So this is not an infrastructure problem and not something infrastructure can fix.

If RHEL-7 dropped the aarch64, why is EPEL-7 still building packages for the architecture?

While I am also on the EPEL board.. this really needs to be discussed over in the EPEL space versus here. https://pagure.io/epel/issue/74

EPEL is not like Fedora releases with full-time staff and product managers. It is instead a community project sponsored by the Fedora group. That means the community has to come together to make it work and the community also expects to have input when changes are made. When RHEL-7.7 came out, that community input was delayed because no one was able to attend meetings due to multiple conferences and PTO.

At the first meeting where the input was gathered, the general consensus was keep it going until it seemed to cause problems. Yours was the first report where it is obvious this will not work and we need to drop this.

I will put in a releng ticket to archive the last set of aarch64 builds to /pub/archive/epel and drop it from the builders.

And my apologies.. I have a broken email filter and this got put in the infrastructure queue for me. I have been acting on this like a infrastructure ticket when this was a releng ticket. THat is completely my fault and I apologize.

The steps needed to fix this ticket are the following:

  1. Archive aarch64 to /pub/archive/epel/7/aarch64/
  2. Remove 7/aarch64 from koji/bodhi
  3. ???

Remove 7/aarch64 from koji/bodhi

@smooge What do you mean by this?

If agreed to today at the EPEL meeting, we would drop aarch64 as a target that koji builds against for EPEL-7. This would then need to go through all the places that aarch64 was defined in which I assume is koji and bodhi.

@smooge What was the outcome of this at the EPEL meeting?

We were hoping to test using CentOS 7.7 for just aarch64 moving forward... but I think we were waiting until that existed.

@kevin Now that CentOS 7.7 is out... Are we able to do this?

Currently this is on the backlog. This week has been 'why is FAS broken?', 'hand sign all the things which FAS problems caused problems', etc etc etc. I don't see this getting attention for a while.

@smooge Can EPEL 7 aarch64 get disabled instead, then?

We finally were able to test this and... yeah, it's not going to work.

So, aarch64 is disabled/dropped. ;(

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

4 years ago

Login to comment on this ticket.

Metadata