[MacPorts] #57133: Don't offer universal variant when multiple architectures aren't supported

[MacPorts]

#57133: Don't offer universal variant when multiple architectures aren't supported
------------------------+----------------------------
 Reporter:  ryandesign  |      Owner:  (none)
     Type:  defect      |     Status:  new
 Priority:  Normal      |  Milestone:  MacPorts 2.6.0
Component:  base        |    Version:  2.5.99
 Keywords:  mojave      |       Port:
------------------------+----------------------------
 When [changeset:e4ed8f58b3d2e33dc86d248d4d4f8e4ce3e0d2ec/macports-base the
 universal variant was added] in MacPorts 1.4.0, it was probably not
 anticipated that we would one day again have a version of macOS that would
 not support multiple architectures. But Apple has stated that macOS 10.14
 Mojave will have reduced 32-bit support and that macOS 10.15 will remove
 32-bit support completely. This will cause numerous problems that we need
 to resolve.

 A change has already been committed to base to
 [changeset:87faa2b7c04210924a051170d46d5577ec5695e8/macports-base set
 universal_archs to just x86_64 on Mojave and later]. MacPorts
 [changeset:46d4fa5fcb16bf300de7161ab23621f4fd4a351c/macports-base prints a
 warning if universal_archs contains only one arch], because current
 MacPorts base code considers that condition to be invalid. This was
 changed to [changeset:0f35ebbacf5f2f3b8e9a3147d69191bb86cceb2b/macports-
 base only print the warning on High Sierra and earlier]. I propose instead
 to remove the warning entirely, and to disable the universal variant (on
 any system version) if `universal_archs` contains only one arch.

 I think we can successfully disable the universal variant by introducing
 special handling for the universal variant in `proc variant` and `proc
 variant_isset`.

 Currently, no special handling for the universal variant exists in `proc
 variant`. If a port or portgroup defines a universal variant with `variant
 universal {...}`, it will be created, and many ports do create the
 universal variant this way. It would be tedious to have to modify each
 Portfile to handle this situation, so I propose we change `proc variant`
 so that if the variant name is `universal` and `universal_archs` contains
 only one arch, the variant is not created.

 Similarly, currently, no special handling for the universal variant exists
 in `proc variant_isset`. And `variant_isset` has the perhaps somewhat
 unexpected behavior that a variant can be set even if that variant is not
 defined. If a user runs `sudo port install someport +foo`, `[variant_isset
 foo]` will return `yes` even if the port has not defined `variant foo`.
 Normally this would not be a problem—why would a port contain code to
 check if a variant is set if it had not defined that variant?—but with the
 universal variant it becomes a problem, because many ports define an empty
 universal variant and then check `if [variant_isset universal]`. Modifying
 each port to check `if [variant_exists universal]` first would be tedious,
 so I propose we change `proc variant_isset` so that if the variant name is
 `universal` and `universal_archs` contains only one arch, it returns `no`.
 I'm not certain if this change will have any adverse consequences, because
 I don't understand why `proc variant_isset` has this peculiar behavior.

 Many ports state a preference for the universal variant using
 `default_variants +universal`. I'm hopeful that no additional changes will
 be needed to handle that, beyond the changes described above.

 There are currently three ports that force the universal variant using
 `variant_set universal` (angband, fakeroot, perforce). These ports should
 be fixed so that they can install for single architectures. We may want to
 modify `variant_set` to error out if the variant name is `universal` and
 `universal_archs` contains only one arch.

-- 
Ticket URL: <https://trac.macports.org/ticket/57133>
MacPorts <https://www.macports.org/>
Ports system for macOS