Opened 6 years ago

Closed 4 years ago

Last modified 4 years ago

#57133 closed defect (fixed)

Don't offer universal variant when multiple architectures aren't supported

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: jmroot (Joshua Root)
Priority: Normal Milestone: MacPorts 2.7.0
Component: base Version: 2.5.99
Keywords: mojave haspatch Cc: cooljeanius (Eric Gallager)
Port:

Description

When 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 set universal_archs to just x86_64 on Mojave and later. MacPorts 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 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.

Change History (6)

comment:1 Changed 6 years ago by jmroot (Joshua Root)

Dupe of #29786?

comment:2 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)

No, that was a different situation which was already resolved.

comment:3 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)

Keywords: haspatch added

comment:4 Changed 5 years ago by jmroot (Joshua Root)

Milestone: MacPorts 2.6.0MacPorts 2.7.0

Ticket retargeted after milestone closed

comment:5 Changed 4 years ago by jmroot (Joshua Root)

Owner: set to jmroot
Resolution: fixed
Status: newclosed

In fcff138bf4a96d41a30774aa03d7269712efc334/macports-base (master):

Remove universal variant if < 2 archs

Fixes: #57133

comment:6 Changed 4 years ago by cooljeanius (Eric Gallager)

Cc: cooljeanius added
Note: See TracTickets for help on using tickets.