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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
