[MacPorts] #53230: preparing port:qt5-kde step 2 : the qt5 PortGroup(s)

[MacPorts]

#53230: preparing port:qt5-kde step 2 : the qt5 PortGroup(s)
----------------------+-----------------
  Reporter:  RJVB     |      Owner:
      Type:  request  |     Status:  new
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:
Resolution:           |   Keywords:
      Port:  qt5-kde  |
----------------------+-----------------

Comment (by RJVB):

 In my current solution, ports that prefer port:qt5-kde would do

 {{{
 set qt5.prefer_kde 1
 PortGroup qt5 1.0
 }}}

 while (rare) ports that really shouldn't be used with port:qt5-kde could
 do

 {{{
 set qt5.prefer_default 1
 PortGroup qt5 1.0
 }}}

 If port:qt5-kde is being used, and thus the qt5-kde PG is loaded, that PG
 does

 {{{
 variant qt5kde description {default variant set for port:qt5-kde* and
 ports that depend on them} {}
 default_variants +qt5kde
 }}}

 in other words, ports built against port:qt5-kde get what I call an `auto-
 default` variant to label them.

 It would be possible to use such a variant to control the choice of
 port:qt5 vs port:qt5-kde; setting it in variants.conf would not be very
 different from the current approach for user who are interested in Qt5
 mainly because of an interest in KF5. The action would need to be
 documented somewhere (the question is *where*!?).[[BR]]
 The main issue I see is that it would make reverting to port:qt5
 cumbersome for users, because installed ports with +qt5kde set will
 require reinstalling them manually without the variant set because there
 is no way to unset a variant programmatically. Not even remove it from
 `default_variants`, apparently.[[BR]]
 On the contrary, and AFAIK, an auto-default variant that is no longer
 defined when port:qt5-kde is no longer used should disappear out of its
 own.

--
Ticket URL: <https://trac.macports.org/ticket/53230#comment:4>
MacPorts <https://www.macports.org/>
Ports system for macOS