If we constrain f-r to be used on the primary architectures(i386, x86_64 for now, arm upcoming) it should be doable to just hardcode these - they are basically all defined from the filename used in mock. E. g. fedora-17-x86_64 ->
- %isa: x86-64
- %_build_arch, %_arch: x86_64
- %rhel: undef
- %fedora: 17
- %_libdir: /usr/lib64

What are the problems using f-r on the secondary architectures? Do we ever make reviews based on secondary architecture builds?

Forgot to comment yesterday. I am not much of a fan of hardcoding, but we could require that fedora-review is run on primary architecture so narrow the problem down. And it's easier to check as well. Relying on the mock config filename is not ideal though. It would be better to rely on config_opts['target_arch'] from mock config I believe.

No, this needs a rethink. Let's try evaluate these macros according to:

• If not using --prebuilt use mock as today to evaluate (don't break working code...)
• When using --prebuilt, require packages to be built for fedora on a primary architecture (i. e., the koji usecase).
• Get the %fedora macro from disttag ('fc17' -> %fedora == 17).
• buildarch is 'noarch' if all packages are noarch , else arch of first found non-noarch package ('i386' or 'x86_64').
• arch is the host platform.
• host platform == i386 && buildarch == x86_64 => error (we don't have the tools to handle x86_64 on i386 platforms).
• %_libdir and %_isa is determined from %buildarch

Fixed in c108ef7dec574953d1a0d

It's not just the macros. It's also about the buildsrc - we use mock to unpack the sources (rpmbuild -bp within mock) also when using --prebuilt. Reopening.

More fixes in 0b1db77bf16b72bed2

Strategy:
- If mock is not available, --prebuilt must be used (check in review_helper)
- Even if --prebuilt is used, it's a point packing up buildsrc using mock. So this is done if mock is available.
- All uses of buildsrc must be guarded by the buildsrc.is_available() check.

Checked by running many packages with mock disabled. Closing