gpsbabel suddenly based on qt5-mac thus leaving qt4-mac-based port qlandkartegt in limbo

[Ryan Schmidt]

On Jun 10, 2015, at 4:07 PM, René J.V. Bertin wrote:
> 
> On Wednesday June 10 2015 13:31:11 Ryan Schmidt wrote:
> 
>> 
>> I don't think Marko is saying that. He's saying he wants to be able to upgrade his ports and have them still work. That's reasonable.
> 
> And between the lines I read that he'd like them to continue to use Qt4 because that's what he has installed, no automagic switching to Qt5. I also don't think it's his style to impose everyone else to continue to provide Qt4 dependent ports by default ...
> A lot of "upstreams" will already use Qt5 if it's available, and it will become increasingly less trivial to override that. There are currently very little Qt5 ports in the repository, but that's by no means representative of the real world outside MacPOrts.
> 
>> You are correct, we don't want ports building themselves differently based
>> on what other ports are installed.
> 
> I think one could and probably should allow for global settings (like port select, or using qtchooser in case of a user's Qt "version preference") that control building behaviour, as a compromise. I'm aware that may not be as trivial as it sounds.

That sounds like variants to me. A port could offer qt4 and qt5 variants. The user can indicate their preferred default by editing variants.conf. But for that to work well, qt4-mac and qt5-mac first have to install to different locations. I haven't been tracking whether that is the change that was recently made to qt5-mac or whether additional work is still needed.

> (Ultimately, ports *do* build differently when a user doesn't have the latest version of all dependencies installed, be it by choice or because the host OS doesn't allow it.)

If you're referring to the case where a user tries to install a port, and it has a dependency that is outdated, then MacPorts will upgrade that dependency first, so that it will build the same as on a system where that dependency was already up to date.

If you're referring to the situation where a port installs a different version of its software depending on the OS X version, for example because a newer version of the software requires a newer version of OS X, then that's an unusual situation, but is not a problem. When I said ports should build the same on every system, I meant for that to be taken to mean on the same OS X version. Certainly a port installed on OS X 10.6 might build differently than the same port installed on OS X 10.10; that's fine.

What we do not want is for one user on 10.10 to install a port "foo" and get the foo software built one way (because they got the binary from our server which doesn't have any optional dependencies installed), and another user on 10.10 got the same "foo" port built a different way, because they happen to build from source and they happened to have some other port "bar" installed that "foo" detected and used just because it was available. If a port is going to vary how it builds, that should be expressed using variants.

https://trac.macports.org/wiki/RepeatableBuilds

> 
>> I don't think we should be recommending maintaining a local ports repository
>> as a solution for users.
> 
> This is the devel ML (and Marko not your average user), right?

If you're suggesting that Marko should use a local repository in order to make copies of the ports that he can modify and improve to the point that those modifications can be submitted for inclusion in the public repository, then that's fine. 

If you're suggesting that Marko should use this method to supersede official portfile behavior, with the intention of continuing to use those local modifications on an ongoing basis, then I don't recommend that, as it could introduce problems for Marko down the road. He would not be made aware of updates to that port available in the public repository, for example, and those updates he misses might be relevant for other ports he has installed.

> 
>> Seems the first step in providing any smooth migration from qt4 to qt5 (for those ports that support that, while still allowing those that don't to remain on qt4) is to make qt4 and qt5 simultaneously installable:
> 
> That's what I have been saying maybe even before Mojca opened the ticket, and I have spent about 6 months or so making this possible. I've even implemented a subport that allows to update qt4-mac to a co-installable version without requiring an immediate rebuild of all the dependents, and have tested about all aspects of that. As a result, port maintainers can upgrade Qt and then rebuild their ports one by one to adapt them to the new system - as far as that's even necessary; well-written ports (= using variables from the portgroup instead of hard-coding paths) will just rebuild and be happy.
> 
>> Seems some action has happened on that ticket lately, though I see you're already aware of that ticket.
> 
> I have the impression you're not even kidding me... Yes, I've been aware of that ticket and the whole issue for at least 10 months.

No, I was not kidding. Sorry; I can't keep track of everything that's going on, and I may forget things. Just wanted to make sure you were aware of what I considered the proper solution for the issue, in opposition to the proposal you made in the message I replied to.