qt5- prefix

[Craig Treleaven]

At 4:11 PM +0100 1/16/15, René J.V. Bertin wrote:
>On Friday January 16 2015 08:27:18 Craig Treleaven wrote:
>
>IIUC, your post isn't related to Qt4/5 
>co-installability, but to how Qt-specific 
>versions of ports distinguish themselves.
>
>>  https://trac.macports.org/ticket/46575
>>
>>  If I understand correctly, Charm will create subports ala:
>>
>>  qt5-charm
>>  charm
>
>Yes.
>
>>  Is this supposed to be a model for going forward?
>
>No idea.
>
>I only picked the qt5- prefix because there's 
>some precedence, though admittedly Qt Creator 
>has a qt4- prefix for the Qt4 version.
>Similarly, GTk ports indeed have -gtk2 or -gtk3 
>suffixes ... though there it might be more usual 
>to have a GTk2 dependency be the implicit 
>default.
>
>>  I find the "qt5-" prefix objectionable.
>
>Frankly, I don't know and I don't have a real 
>preference: I'm open to suggestions.
>We do have the likely situation where more and 
>more ports will transition to, or at least add 
>support for, Qt5. As long as MacPorts doesn't 
>provide a mechanism to signal a port name change 
>and thus let user installations go from, say, 
>QtCurve to qt4-QtCurve automatically, I don't 
>see another solution of the kind I've adopted in 
>my 2 proposals (Charm and QtCurve).

The replaced_by keyword (and obsolete PortGroup) support what you've described:

https://guide.macports.org/#development.practices.rename-replace-port


>  > Going forward, I believe we will have the following cases:
>>  1) Projects that work with Qt4 but not Qt5
>>  2) Projects that work with Qt5 but not Qt4
>>  3) Projects that work with either Qt4 or Qt5 but differ in non-trivial ways
>>  4) Projects that work with the same with Qt4 or Qt5
>>
>>  Assuming we have co-installable Qt4 and Qt5 via
>>  MacPorts, cases 1), 2) and 4) are
>>  straightforward:  'port:' style dependencies for
>>  1) and 2) and 'path:' style for 4).
>
>AFAIC, case 4) ports will either impose a choice 
>(port: style dependency) or leave choice to the 
>user, as I did with Charm.

As port maintainers, I believe we _should_ make 
choices on behalf of users.  Case by case, 
revision by revision, if there is a choice 
between Qt4 and Qt5, the port maintainer should 
evaluating whether to stay with Qt4 or jump to 5. 
At some point, I suspect security problems with 
Qt4 (or just bit rot) are going to push projects 
to give up on Qt4.  IOW, sub-ports or variants 
for Qt4/Qt5 should be unusual exceptions rather 
than the norm.  Pick the right time and make the 
move.  Use a -devel port if experimentation is 
required in the interim.

>There is something to say with providing a 
>version-agnostic Qt PortGroup that could even 
>include the version-specific PortGroup, though.

Could you clarify what you mean here?

>  > OTOH, there might be rare cases where users might
>>  need to choose between the Qt4 version (more
>>  compatible, say) and a Qt5 version (new
>>  features).  Qt4/Qt5 variants would then be
>>  appropriate.
>
>If you accept that detection of the installed 
>version is done automatically, yes. But when you 
>do that, how do you handle the case the user has 
>both Qt versions installed? Even if you as a 
>port developer (knowing the port and all) have a 
>preference, the user might not agree.

To be blunt, tough.  If a user really wants 
another configuration, they can create a modified 
portfile for themselves.  The port maintainer 
ought to pick one variant as the default.  My 
impression is that the vast majority of installs 
use only the default variants.  We shouldn't shy 
away from the doing the right thing for (the 
majority of) our users.

I see the Qt5 supports OS X 10.7 and later ('best 
efforts' for 10.6, if I read it right):

http://doc.qt.io/qt-5/osx.html

For some ports, if the maintainer wants to keep 
it running on old OS X versions, they might use 
Qt4 for older OS environments and Qt5 for newer. 
Not a variant, just do the right thing in the 
environment.

Craig