Created attachment 213768 [details] [build log] pyside2 configure failure cmake fails with a less than helpful "Configuring incomplete, errors occurred". No hints as to what the errors were. I am taking hints to help figure out what the error is.
It seems there's a missing dependency for qt5-imageformats. An older version of qt5-imageformats (5.13.2) was installed and some of the cmake macros defined therein changed for 5.14.2.
Created attachment 213770 [details] [patch] USE_QT+=imageformats Add imageformats to USE_QT. This may not be appropriate, but it worked such that the dependency is noted (and can be acted on by tools such as portmaster). Due to the nested dependencies, the cmake modules for imageformat get called, so there's at least some tenuous dependency from pyside2 to qt5-imageformats at least. Maybe they shouldn't called be if they aren't needed - that would be a different bug, but the twisted maze of dependencies is hard to follow. Have I said I dislike cmake? I leave it to you, fearless maintainer. We could say that there's a hacky workaround to delete an old qt5-imageformats pkg that may be installed, but that is not very satisfying - not pleasant for users or maintainers.
This is a good one - but I don't think it's pyside2 which is to blame here. - nothing in pyside2 references Qt5ImageFormats - it's not even an "optional" module to be wrapped via pyside2. I'll argue that the real culprit here is qt5-gui: Qt5GuiConfig.cmake pulls in all files ${LOCALBASE}/lib/cmake/Qt5Gui/Qt5Gui_*Plugin.cmake (see Qt5GuiConfig.cmake line 212) - and out friend qt5-imageformat drops a bunch of image format (duh) plugins there. From the history of qt5-imageformat's pkg-plist, the list of plugins hasn't changed for a long time, but of course you'll get funny results if you're mixing Qt 5.13 and 5.14. I would suspect that all ports using qt5-gui via the "official" cmake interfaces will suffer breakage on this mismatch. And as it's qt5-gui's cmake file which is pulling in "all the plugins", it should be qt5-gui's responsibility to run-depend on qt5-imageformats. Otherwise every consumer of qt5-gui would have to chase the same problem - and the problem isn't even reproducable in poudriere or any other clean system, as no old qt5-imageformats would exist there. Let's hear what kde@ has to say about this.
(In reply to Christoph Moench-Tegeder from comment #3) Moin moin Mixing Qt-versions is not supported. mfg Tobias
(In reply to Tobias C. Berner from comment #4) Yes, of course, "funny results". But still qt5-gui pulls in whatever files it finds, including plugins installed by qt5-imageformats while it has no dependency on qt5-imageformats. When building upgrade in-place (which I don't really recommend, use poudriere, etc) this may result in situations like the one in this PR: qt5-gui has been upgraded but there's still the old qt5-imageformats, and then everything depending on qt5-gui will fail to build. Five (obvious) options: - tell people no to use portmaster/portupgrade/etc - every consumer of qt5-gui has to depend on qt5-imageformats, too - make qt5-imageformats a runtime dependency of qt5-gui, forcing that package to be present and current - don't collect random files in qt5-gui - some better idea First option would be mightily unpopular, second option forces a false dependency, third option solves the problem once-and-for-all, fourth option breaks existing and expected behaviour, fifth option "?". What now?
(In reply to Christoph Moench-Tegeder from comment #5) Ideally qt.mk would also enforce a ">=${_QT_VERSION}" dependency. At the moment it most of the times creates a LIB_DEPENDS for the components. I can take a look how complicated it would be to additionally always also generate a BUILD_DEPENDS. So that for example USE_QT=gui would add LIB_DEPENDS=libQt5Gui.so:x11-toolkits/qt5-gui BUILD_DEPENDS=qt5-gui>=5.14.2:x11-toolkits/qt5-gui This would at least enforce an upgrade of the components. Still in the end, I think that people should simply stop using portmaster/portpugrade :) I try to modify qt.mk tomorrow [tm] mfg Tobias
Created attachment 213790 [details] v1 The attached patch will do that...
(In reply to Christoph Moench-Tegeder from comment #5) portmaster is not the problem here - don't blame it. This can happen without portmaster. The core ports infrastructure (make && make install) still needs to be "right". The problem here is a question of dependencies / pollution mostly. If pyside2 breaks because there is an older qt5-imageformats is installed, then there is a missed dependency somewhere (indirect though it may be). Or pyside2 (or dependencies of pyside2) could explicitly disable things that might be installed and get pulled in that it doesn't need. Or best, the cmake infrastructure should avoid pulling in things it doesn't need (this is similar to system include file pollution issues). qt5-gui can't (shouldn't) record a dependency on qt5-imageformats because qt5-imageformats is (currently) dependent on qt5-gui. That'd be a circular dependency. I haven't tried at Tobias' patch yet or confirmed that it helps the underlying problem. I do agree that adding imageformats as a dep in this port is not right (since it does not knowingly, directly use qt5-imageformats in any way).
(In reply to John Hein from comment #8) > qt5-gui can't (shouldn't) record a dependency on qt5-imageformats because qt5-imageformats is (currently) dependent on qt5-gui. That'd be a circular dependency. Maybe pyside2 should depend on py-qt5-gui? I don't think Tobias' qt.mk patch helps with the underlying cause of this bug.
(In reply to Tobias C. Berner from comment #6) qt5-gui was updated, but qt5-imageformats was not. Since the latter is not a dependency in any way (directly or indirectly) of pyside2, I don't think this patch would have helped in this case. Also I don't think having a build dep in addition to lib dep is necessary in other cases either. Both build & lib deps generally need to be satisfied by the time a port that needs either build or lib dep gets to its configure stage. Maybe there's some edge case where this is important, but this bug isn't the one that should trigger this change I believe.
(In reply to Tobias C. Berner from comment #7) You're doing way too much here: all we need is for qt5-gui to depend on qt5-iamgeformats, That would ensure that qt5-imageformats is always installed and upgraded before qt5-gui gets upgraded. Your patch isn't wrong, but fixes a different problem :)
(In reply to John Hein from comment #9) py-qt5-* is the other Python-Qt-framework - depending on that wouldn't be right, either. The core of the problem still is qt5-gui picking up files from qt5-imageformats: first, that can result in differing builds depending on whether qt5-imageformats is installed or not; second, the order of packages during upgrades may be wrong and we're mixing an old qt5-imageformats with the new qt5-gui (which does not work,a s you experienced first hand).
(In reply to John Hein from comment #8) > portmaster is not the problem here - don't blame it. This can happen without > portmaster. The core ports infrastructure (make && make install) still needs > to be "right". portmaster is fine when you build on a clean system - no old packages installed, etc. But when you remove all packages every time you update your ports, you'd be better of by using poudriere anyways. With the complexity of today's software and build systems (scripts generating input for other scripts generating Makefiles - don't get me started, but then I wouldn't want for developers doing that with raw shell scripts, that didn't work either), building in not-that-well-defined evironments will give not-so-well-defined results.
(In reply to Christoph Moench-Tegeder from comment #11) As I said earlier, you can't have qt5-gui depend on qt5-imageformats - that would be a circular dependency. I agree that the cmake should not bring in more than it needs. That's a tough problem, but that doesn't mean it's not important. And unfortunately, it's too common for developers to "include" things that are not necessary for just what is being asked for. I don't see any solution for this problem, so I'm inclined to just close it unless someone has a good idea.
(In reply to Christoph Moench-Tegeder from comment #11) Yes, I was mostly concerned with the "mixed Qt" left behind by some tools, which my patch at least would partially improve [tm]. Maybe we should look into whether the dependency we have betweeen qt5-gui and qt5-imageformat is actually required, or whether it as moved on in the past few releases. I'm putting this on kde@'s TODO list.
I didn't mean to close this so soon - until others had a chance to add a possible solution. And I certainly didn't mean to mark it FIXED. I'll leave it closed (but not FIXED). If you have a good idea to fix the underlying issue, feel free to suggest.
(In reply to John Hein from comment #16) There is also a different question we can ask: is there a reason we split imageformats out from gui? As the maintainer I would be happy to reduce the number of ports create from a single qt-dist tarball (which is a lot of work). So if "almost" all the ports requireing image-formats also use gui, and vice- versa, then the two ports should/could be merged, and this bug would resolve itself.
(In reply to Tobias C. Berner from comment #17) I can't claim enough familiarity with qmake/qt ports to answer that well. If it solves a problem from your point of view, it's worth consideration. There's always something of a balance between a port being too large and too small. As far as I can see almost all the (13) ports that need qt5-gui also need qt5-imageformats [1]. One (graphics/openorienteering-mapper) requires only -gui outright, but then also pulls in -imageformats if an option (TIFF) is on. qt5-imageformats is not particularly big, so it won't be a big additional size burden or large added build-time load for qt5-gui (probably just 10-20 seconds on a modest build box). Sorry I can't offer a better answer now. Maybe someone else can add. [1] https://www.freshports.org/graphics/qt5-imageformats/
(In reply to John Hein from comment #18) I guess the other perspective is that qt5-gui is too big and could be broken up. I suspect that's not the case here, and certainly understand how that can make maintenance harder. I think there are examples where an effort to break up something large paid off, but those are generally initiated upstream.