[MacPorts] #51643: qt5 portgroup overwrites supported_archs, defines universal variant when one is not desired

[MacPorts]

#51643: qt5 portgroup overwrites supported_archs, defines universal variant when
one is not desired
--------------------------+------------------------
 Reporter:  ryandesign@…  |      Owner:  mcalhoun@…
     Type:  defect        |     Status:  new
 Priority:  Normal        |  Milestone:
Component:  ports         |    Version:  2.3.4
 Keywords:                |       Port:  qt5
--------------------------+------------------------
 I'm trying to update my QupZilla port to version 2. It now requires qt5
 instead of qt4. It also now requires an x86_64 processor.

 Without using any portgroup, setting `supported_archs x86_64` in a
 portfile causes the universal variant to be disabled. That's what I want.
 But something different happens when using the qt5 portgroup:

 * If I set `supported_archs x86_64` before including the qmake5 portgroup,
 the qmake5 portgroup includes the qt5 portgroup which overwrites my
 `supported_archs` choice.
 * If I set `supported_archs x86_64` after including the qmake5 portgroup,
 the qmake5 portgroup includes the qt5 portgroup which includes the
 muniversal portgroup which defines a universal variant.

 It looks like the only way to make a working portfile with the way the qt5
 portgroup is written today is to set `universal_variant no` before
 including the qmake5 portgroup and to set `supported_archs x86_64` after
 including the qmake5 portgroup. That's inelegant.

 It would be simple enough to modify the portgroup to set a ''default'' for
 `supported_archs` but not overwrite a value if the port already set one.
 Ideally, the portfile author should be able to specify `supported_archs`
 or `universal_variant no` later in the portfile, as is customary, but I'm
 not sure how the portgroup would then be able to set up the universal
 variant correctly for those ports that need it.

 The app portgroup handles a similar situation (whether or not to add the
 makeicns dependency) using variable traces. That's a bit messy, but I
 can't think of another way to handle it.

-- 
Ticket URL: <https://trac.macports.org/ticket/51643>
MacPorts <https://www.macports.org/>
Ports system for OS X