Correctly represent 64-bit platform as x86_64 in ${os.arch} and pre-generated PortIndex

[raimue (Rainer Müller)]

This initialization code in ​macports1.0 is currently folding all x86 platforms into the i386 arch:

if {$os_arch eq "i586" || $os_arch eq "i686" || $os_arch eq "x86_64"} {set os_arch "i386"}

However, it seems incorrect to do that for x86_64. Especially now that Apple is about to ​remove support for 32-bit apps, this should be corrected in the output of port platform to avoid confusion.

Portfiles may use it in a platform ... {} block, and a couple of Portfiles are using it in the ports tree with i386, although the current meaning is actually any of i386 or x86_64. The actual intention of these platform blocks would probably be to match on ${build_arch} and not on ${os.arch} anyway.

Furthermore, this value is also used to fetch a matching PortIndex for the current platform. When the mentioned change in Portfiles was done, the PortIndex files should also be built based on ${build_arch} and not ${os.arch}. Therefore this also requires changes to the jobs creating the PortIndex to additionally provide x86_64 where appropriate.

[ryandesign (Ryan Carsten Schmidt)]

Who's to say that how we're currently handling os.arch is "incorrect"? Up to now, it has always been the case that os.arch is "powerpc" on 32-bit or 64-bit PowerPC systems, and "i386" on 32-bit or 64-bit Intel systems. This is neither "correct" nor "incorrect", it's just what we decided to do, a long time ago. Hopefully every part of base and most ports interpret it that way. Why do we want to go to all the effort of changing it and possibly breaking things that rely on the existing behavior?

[raimue (Rainer Müller)]

I think this problem currently hits us with librsvg on arm64. The PortIndex contains version 2.52.4 for arm64, and is always reported as outdated to users that have version 2.40.20 installed. But when the user actually tries to upgrade, nothing happens, because parsing the Portfile will see version 2.40.20.

This happens because the Portfile is [conditional ​https://github.com/macports/macports-ports/blob/b3d5a287abc43bdd61630c2bef201e2ee3d0a8d4/graphics/librsvg/Portfile#L70] on ${build_arch}, but this option is not spoofed by portindex when generating the PortIndex for a non-native macOS version.

[jmroot (Joshua Root)]

IMO the only workable way to handle the problem described in comment:2 is to not have ports that dynamically change their version. If a different version is needed, it should be installed by a different port or subport.