#233 for ppc64 we need to ship both ppc64 and ppc64p7 variants
Closed: Insufficient data Opened by pbrobinson.

ppc64 has a terrible hack where they have a selection of p7 optimised binaries. One example of this is python3. We some how get python3-3.5.1-7.fc24.ppc64.rpm and python3-3.5.1-7.fc24.ppc64p7.rpm but only the ppc64p7 variants of python3-libs and all the other sub packages as can be seen here:

https://dl.fedoraproject.org/pub/fedora-secondary/development/24/Everything/ppc64le/os/Packages/p/

I'm not sure if we're using dnf for the pungi process but I suspect if we are this might be part of the issue


Dnf is not involved in any way. Yum is used currently. Daniel has a branch with port to DNF.

From what I gathered so far: the repo with all the packages has python3-libs for both ppc64 and ppc64p7. Config for depsolving does not have any specific requirements on that package.

Log of the depsolving shows it found python3-libs.ppc64p7 only. The version for ppc64 is not mentioned at all.

For some reason the package must be getting excluded in pungi/gather.py. Looking at the code, since greedy method is set to build, yum picks what it thinks is the best package.

If I change the greedy method to all, it will include both arches. There will likely be other extra packages, though. The config option for this is greedy_method.

Is this still an issue? Looking at the latest Rawhide and branched composes, there are no packages with ppc64p7 arch anymore.

Metadata Update from @lsedlar:
- Issue close_status updated to: Insufficient data
- Issue status updated to: Closed (was: Open)

For reference: We killed off the ppc64p7 sub arch. It was a terrible hack, wasn't well supported in dnf (or in general). In the future the optimisations will be done using IFUNC in glibc/gcc.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/pungi/pungi/issues/233

Please continue any further discussion there.

Metadata