Re: Using qt59 instead of qt5 (latest release)

[Craig Treleaven]

> On Apr 4, 2018, at 9:54 AM, Vincent Habchi  wrote:
> 
> Hey Craig,
> 
>> I am considering a similar move for mythtv.28.  
> 
> […]
> 
> Thanks for that useful info. French has a saying which goes like this (more 
> or less, it’s difficult to translate): “The best is oftentimes the good’s 
> enemy”.
> In any case, yeah, I suppose this will mean at least writing variants. What I 
> am more weary of is py-qt5. I hope the latest version is backwards compatible 
> with earlier releases of Qt5.
> 
> Probably going to do that later in the week.
> 

I was wondering if the Qt5 portgroup could be modified so that dependent ports 
don’t automatically upgrade to the absolute latest version of Qt 5.  Just 
spitballing, but what if the portgroup had a directive like:

prefer_QT5_version -1

If the currently released version is 5.10, this would indicate that we want to 
use 5.9.  When 5.11 is released, presumably 5.10 would be mature enough that it 
would be safe to upgrade to it.

Or perhaps:

prefer_Qt5_LTS_version [-1]

Qt 5.9 is the current long term support version and Qt 5.6 is the previous LTS. 
 

Thoughts?  Are most Qt5-dependent ports happy to keep up to the latest Qt 
release?  It appears to be a concern for Vincent and myself.

Craig

Re: Using qt59 instead of qt5 (latest release)

[Vincent Habchi]

Hey Craig,

> I am considering a similar move for mythtv.28.  

[…]

Thanks for that useful info. French has a saying which goes like this (more or 
less, it’s difficult to translate): “The best is oftentimes the good’s enemy”.
In any case, yeah, I suppose this will mean at least writing variants. What I 
am more weary of is py-qt5. I hope the latest version is backwards compatible 
with earlier releases of Qt5.

Probably going to do that later in the week.

Once again, thanks for chiming in.

Have a great day!
Vincent

Re: Using qt59 instead of qt5 (latest release)

[Craig Treleaven]

> On Apr 4, 2018, at 8:33 AM, Vincent Habchi  wrote:
> 
> Hi there,
> 
> I recently wanted to experiment with linking one of the ports I maintain 
> (Qgis3) with QT 5.9, if only to find out if 5.10 wasn’t the source of all the 
> glitches and crashes everyone experiences with that application. 
> 
> However, in order to do so, I’d have to rebuild several dependents such as 
> py36-qt5 or qwt-qt5 (inter alia). Are those able to deal with a Qt5 version 
> other than the last one?
> 

I am considering a similar move for mythtv.28.  

Looking at qwt-qt5, I think you’re going to have a problem.  As the port now 
stands, it does not appear to support any Qt5 versions other than the latest:

$ port info qwt-qt5
qwt-qt5 @6.1.3_2 (graphics, science)
Sub-ports:qwt-qt5-examples
…
Library Dependencies: qt5-qtbase, qt5-qtsvg, qt5-qttools
…

Another issue is Qt5 v. macOS versions.  When I last looked, a couple of months 
ago, it appears that Qt 5 has NO official support for macOS 10.13.  Has that 
changed?

Qt 5.7 and 5.8 were no longer officially supported.

Qt 5.6 is supported until next March (2019) but not on macOS 10.12 or later.

Qt 5.9 is supported until 2020 on 10.10, 10.11 and 10.12.  

I don’t follow the Qt5 project that closely; I don’t know what the practical 
implications of “official support’ really are.  It certainly appears that 
various versions of Qt5 “work” on High Sierra.  OTOH, I think there are 
interface problems with MythTV under Qt 5.10.  I hope these will go away by 
rolling back to, say Qt 5.6.  

BTW, out of about 2,900 MythTV Linux systems using Qt5 (in their voluntary 
reporting system), nearly 2,200 are running Qt 5.5.  Another 300 are running Qt 
5.7.  Only 3 are running Qt 5.10.  A further 1,000 users are still running 
older versions of Myth that require Qt 4.

Craig

Using qt59 instead of qt5 (latest release)

[Vincent Habchi]

Hi there,

I recently wanted to experiment with linking one of the ports I maintain 
(Qgis3) with QT 5.9, if only to find out if 5.10 wasn’t the source of all the 
glitches and crashes everyone experiences with that application. 

However, in order to do so, I’d have to rebuild several dependents such as 
py36-qt5 or qwt-qt5 (inter alia). Are those able to deal with a Qt5 version 
other than the last one?

TIA,
Vincent