[MacPorts] #49721: dangerous bug in Qt5

[MacPorts]

#49721: dangerous bug in Qt5
--------------------------+------------------------
  Reporter:  rjvbertin@…  |      Owner:  mcalhoun@…
      Type:  defect       |     Status:  assigned
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:  qt5          |
--------------------------+------------------------

Comment (by rjvbertin@…):

 Replying to [comment:7 mcalhoun@…]:

 > * There is a program out there that runs
 {{{removeDir(ApplicationsLocation)}}} assuming that it is deleting a
 folder in {{{~/.qttest}}}
 > * This assumption has catastrophic results on OS X.

 There could be any number of such (test) programmes. Part of my current
 routine in writing KF5 ports is to verify all auto-tests for dangerous
 behaviour, and replace the port test settings with a warning when I get a
 hit (and KF5 is being built without my QSP patch).

 > {{{isTestModeEnabled()}}} return true, what is
 {{{ApplicationsLocation}}} on Windows and Linux that would make
 {{{removeDir(ApplicationsLocation)}}} safe?[[BR]]

 No idea on MS Windows (look at the relevant Qt code...) but on Linux we're
 talking about `$HOME/.local/share/applications` vs
 `$HOME/.qttest/share/applications`. Also, ApplicationsLocation doesn't
 contain the actual applications but only files with metadata pertaining to
 applications.

 > Doesn't {{{removeDir(ApplicationsLocation)}}} delete '''ALL''' other
 application testing data and not just for that particular program?[[BR]]
 > Are you simply not supposed to run two tests at the same time?

 Yes, and yes I guess. Of course if you do, and test b removes stuff test a
 requires, all that happens is that test a fails. You'll then try test a
 again, and it'll succeed ... and you'll end up understanding that you're
 seeing expected behaviour.

 > This sounds like a problem that needs to be addressed either upstream or
 with the unit test writers.[[BR]]
 > I would suggest submitting a bug or a patch with either group.

 As I said before, Qt is aware, and a fix will appear, but probably later
 rather than sooner. I also don't know if the issue will address the fact
 that ApplicationsLocation does not have the same meaning across platforms.
 That is something that will have to be solved independently.
 Unit test writers are not doing anything wrong, the bug is not theirs, and
 without documentation saying that ApplicationsLocation should not be used
 on OS X they have no reason to take that into consideration.

 The plan is to re-submit my QSP patch to Qt at some future time when it
 will have had sufficient real-world testing; changes to QStandardPaths as
 well as the activator principle to toggle QSP from "native" into "XDG-
 compliant" mode.

-- 
Ticket URL: <https://trac.macports.org/ticket/49721#comment:8>
MacPorts <https://www.macports.org/>
Ports system for OS X