[MacPorts] #51619: qt5.depends_component procedure

[MacPorts]

#51619: qt5.depends_component procedure
---------------------------+----------------------
  Reporter:  RJVB          |      Owner:  mkae
      Type:  enhancement   |     Status:  assigned
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:
Resolution:                |   Keywords:
      Port:  qt5, qt5-kde  |
---------------------------+----------------------

Comment (by RJVB):

 Replying to [comment:18 MarcusCalhoun-Lopez]:
 > Please correct me if I am wrong, but we have three major design goals:

 I would use this order:

 > 1. Minimal disruption of ports that use Qt.
 > 1. Support a patched version of Qt which is necessary to be used with
 KDE.
 > 1. Allow the installation of older versions of Qt to accommodate older
 OSs.


 > Here are the options I can determine:
 > 1. Let the user decide which Qt to install with reasonable defaults.
 >  * This seems to be the current path.
 Indeed.
 >  * Runs contrary to ReproducibleBuilds and MacPorts philosophy in
 general.

 Again, it doesn't have to violate the reproducible build approach as far
 as I understand it. It *is* somewhat of a novel approach for MacPorts, but
 then the situation is novel(ish) too. Though there are similarities with
 the libressl vs openssl situation (and I think I have prepared a more
 elegant implementation for port:qt5 vs port:qt5-kde!)

 >  * There might be (and probably are) any number of ABI comparabilities
 that we don't know about.

 The whole discussion about ABI compatibility has probably distracted us
 from a rather important point. This is a problem that plays only when
 changing from one port to another. Once you install port:qt5-kde, the
 +qt5kde variant my portgroup introduces is going to protect against
 pulling possibly incompatible binary builds from the bots. This means that
 users who install `port:qt5-kde` will install standard Qt5 ports from
 source, and when they change back to port:qt5 they may have to reinstall
 those ports. The same thing happens with GTk X11 vs. XQuartz as far as I
 know, or LibreSSL vs OpenSSL. It's a choice they make, and we can document
 such implications.

 In practice I would expect that most users will decide once which Qt5 port
 they install and then stick to it.

 > 2. Variants (`qt5`, `qt56`, `qt5-kde`) defined in `qt5-1.0.tcl` to
 conflicting Qts.
 >  * The various GTK ports had to jump through quite a few hoops with
 `+x11` vs `+quartz`. The various maintainers have done a wonderful job,
 but, from the outside, it looked like quite a bit of effort. I am not sure
 I want to have allot of `require_active_variants` in client ports.
 > 3. Variants (`qt5`, `qt56`, `qt5-kde`) defined in `qt5-1.0.tcl` to non-
 conflicting Qts.
 > 4. Completely separate `qt5` and `qt5-kde`

 I am sure I do not want to have to impose the use of the active_variants
 PortGroup, and also that I don't want to have to guess about the side-
 effects of potentially having a different Qt version installed somewhere
 in the same prefix. Those 3 options will more or less oblige me to declare
 conflicts with port:qt5 in port:qt5-kde, and that's going to cause a big
 problem with ports like qca-qt5, poppler-qt5 etc. which are dependencies
 for both regular Qt5 applications and Qt5-kde applications.

 > 5. Attempt to merge `qt5` and `qt5-kde`
 >  * The necessary KDE patches would be added via a variant in `qt5`.
 >  * The Qt version would be determined by the OS and cxx_stdlib.
 >  * `require_active_variants`might still be necessary in client ports,
 but probably not many.

 Require_active_variants would be required in all KF5 ports because there
 would no longer be a way to indicate a preference.
 Either way, the Option 5 ship has sailed over a year ago.

 > If I understand correctly, Mojca has raised serious concerns about (1)

 Where? Mojca, is this true? I know you've been following my qt5-kde
 submission ticket from an early stage but cannot recall that you voiced
 any serious concerns there?


 > René has [https://lists.macports.org/pipermail/macports-
 dev/2016-October/033944.html expressed reservations about (5)].

 > Based on the numerous discussions we have already had, I thinks it is
 fair to say that a perfect solution is unlikely to present itself.[[BR]]
 > I am willing to work on any of the solution, but my order of preference
 is (5), (4), (1), (2), then (3).

 My preference is evidently with the current approach, option 1). I've had
 a lot of time to think about this, and I think it's the only approach that
 allows to introduce KF5 in a way I can really stand behind. It's also the
 approach that puts the least additional maintenance effort on Marcus and
 maintainers of other ports depending on Qt5. I have already stated that
 I'm willing to carry the brunt of the maintenance of the shared PortGroup,
 but for the rest responsibility of everything related to the current
 port:qt5 will remain with Marcus, and I will keep in sync with any chances
 he makes that have implications for the compatibility between the ports.
 That's not just minimal disruption of ports that use Qt, it's also minimal
 disruption of all port maintainers except myself (but then guess who's
 proposing to introduce another Qt5 port :)).
 (There *is* the question of shared maintenance of the qmake5 PG of course
 but there too I have already re-organised the file to make it clear which
 parts are shared and which aren't).

 The only other option I see is to include the QStandardPaths patch into
 port:qt5, without using a variant (just including the patch doesn't change
 Qt's default behaviour). That is probably the only adaptation for KF5 that
 is really required, though I cannot fathom nor guarantee how well things
 will work with the installation layout used by port:qt5 . They may simply
 work, but maybe they won't; the different and very non-standard location
 of the CMake modules may be an issue, for instance.

 Actually, I do see another option, and that's to keep on proposing the KF5
 ports as I do at the moment: as a custom ports tree with instructions on
 how to use it. But that would be somewhat of a pity.

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