How to deal with ports-filesystem violation?

[René J.V. Bertin]

On Monday June 29 2015 01:15:19 Marko Käning wrote:

>Ha, I did that a year ago already, but I am not keen to patch Qt5 itself anymore,
>since this had been discussed at length with the Qt devs. They eventually argued
>that Qt5 and all apps based on it should make use of OSX’ standard directories and
>thus let QStandardPaths (QSP) succeed and not tweak anything in Qt’s code base.

No, this is NOT how I understand it. There have been questions why the current Mac-like approach isn't appropriate, but there was certainly no consensus that we just should put up with it already.
I'll try to repeat this once more: in my understanding, we failed to make a sufficient argument for modifying Qt upstream. They implemented QSP the way it is with valid reasons from their POV (admissibility to the App Store being a very important one that should be completely moot for MacPorts) but they haven't excluded the possibility to accept a patch. There *is* appreciation for the fact that something like MacPorts has valid reasons to want to be able to do things differently, and that this probably requires patching QSP in a way that it can behave both ways. For instance with a link-time switch that toggles QSP from the default "Mac-like" behaviour to something "linuxy"

The problem with patching Qt upstream is that it's a very heavy-handed procedure, more so that I'd expect even from a widely-used middleware that's also available as a commercial product. For one, we'd be looking at a code-review for Qt 5.6 at the earliest, meaning we'd be maintaining a patch against a shifting code-base while still working on getting it just right 2 releases down.
Hence my suggestion that we'll need to come up with something that works first, and only then and when there's sufficient evidence that QSP isn't evolving otherwise re-attempt an upstream patch.

>However, René was courageous enough to patch qt5 anyways [3] and I guess it is up
>to the MacPorts team to somehow decide, which way we should go wrt to Qt5’s QSP.
>A QSP-patched Qt5 would certainly have the MacPorts-ish advantage of
>
>   “freedom of choice” wrt letting all files live under the MacPorts-prefix
>                       in locations where they are also to be found on Linux
>
>as René formulated it a couple of times.

It's not just the freedom of choice thing of course; it's what comes with it. MacPorts has "pure" Qt applications in ports (like Qt Creator or Charm) that either don't care where they get their stuff from exactly, or are cross-platform anyway (or that can be tweaked where required to cope with an install schema that's not "Mac-native"; Michael might know more about this re: Qt4 apps). And it's intended that there will be KF5 versions of all applicable KDE4 ports that exist currently, the majority of which are conceived to function in a FreeDesktop.Org context. Building them with Qt5's current QSP layout has proven to be difficult, and beyond that issues are to be expected with icon themes and all that other stuff that's also used by the GTk/Gnome/XFCE ports.

Beyond that, I continue to think that getting KF5 apps to function correctly on OS X is going to be hard enough without having to factor in a completely different layout of the support directories. There's something to be said for getting those KF5 apps to work with the native layout, but I see that as 1) a secondary point to be addressed only when everything works correctly otherwise and 2) something that doesn't really seem to correspond to MacPorts' mission statement.

R.