This very likely has something to do with my "reverse usr-merge" layout: /usr -> . So what would normally be /usr/lib64/ canonically resolves to /lib64. If something's canonically-resolving the path for, say qtcore, and trying to use that as the installation path for the static-lib *.a files, instead of installing them in the normal /usr/ path, that would result in installation to /lib64, which would of course trigger this QA warning in portage. But why did several other dev-qt/* packages merge beyond qtcore, before qtdeclarative caused problems, and why didn't earlier versions of qtdeclarative (including the merged 5.13.2 that I'm trying to upgrade) trigger similar issues? Here's the emerge pretend output for USE flags: [ebuild U ] dev-qt/qtdeclarative-5.14.0_beta3:5/5.14::qt [5.13.2:5/5.13::gentoo] USE="jit widgets -debug -gles2 -localstorage -test" 0 KiB And the error (full build log attached): >>> Completed installing dev-qt/qtdeclarative-5.14.0_beta3 into /tmp/portage/dev-qt/qtdeclarative-5.14.0_beta3/image * Final size of build directory: 323676 KiB (316.0 MiB) * Final size of installed tree: 29336 KiB ( 28.6 MiB) * * The ebuild is installing to one or more unexpected paths: * * /include * * Please fix the ebuild to use correct FHS/Gentoo policy paths. * QA Notice: Excessive files found in the / partition * /tmp/portage/dev-qt/qtdeclarative-5.14.0_beta3/image/lib64/libQt5PacketProtocol.a * /tmp/portage/dev-qt/qtdeclarative-5.14.0_beta3/image/lib64/libQt5QmlDebug.a * /tmp/portage/dev-qt/qtdeclarative-5.14.0_beta3/image/lib64/libQt5QmlDevTools.a * ERROR: dev-qt/qtdeclarative-5.14.0_beta3::qt failed: * static archives (*.a) and libtool library files (*.la) belong in /usr/lib*, not /lib*
Created attachment 597434 [details] emerge --verbose --info qtdeclarative
Created attachment 597436 [details] full build log, xz compressed
[Sorry, this feels like poorly explaining to the experts what I suspect they can better explain to me, but what do I leave out and still properly describe ...?] The warning itself is of course a QA check from portage, found in (portage's) ${S}/bin/install-qa-check.d/80libraries (installed as /usr/lib/portage/$PYVER/install-qa-check.d/80libraries), lib_check function, in the "# Make sure people don't store libtool files or static libs in /lib" check, starting on line 155 in portage-2.3.79. That check triggers the die on line 162 (again, in the portage file) with the "static archives ... belong in /usr/lib ..." die message that's the error above. While that's normally fine and good, and does not *normally* trigger here because in the (pre-live-merge) fake-install image that it checks /usr continues to be a separate directory, which only happens to end up at the same libdir as / on my merged live system, obviously something's going wrong with the build system here and it's merging the dirs in the fake-install image as well, thereby triggering the die. Unfortunately portage doesn't appear to have a QA_* var or the like I can set to bypass this and continue testing, so I ended up test-patching portage to change the die into a non-fatal QA_WARN. That allowed me to test-bypass the warning and continue the install, not a real problem here since on my live system it's the same dir in any case. Which allows me to finish merging all of qt-5.14.0-beta3 (with a few more such warnings due to the same bug in other qt packages, but the same fix should fix it in all I expect) that I need for what I have installed of kde, etc, EXCEPT for qtwebengine-5.14.0-beta3, which builds fine, but then ends up tripping over its bug #601472 check in src_install(). But unsurprisingly given this bug the file it's checking for is there, ${D}/lib64/libQt5WebEngine.so, just not the tested ${D}${QT5_LIBDIR}/libQt5WebEngine.so, where ${QT5_LIBDIR} apparently remains /usr/lib64 as it should be. So apparently ${QT5_LIBDIR} remains correct, and the bug appears to be, as I said, something in the build system presumably detecting and using the live-system-canonical-path /lib64 instead of the standard /usr/lib64 that it's supposed to use (and that's apparently still correctly set in ${QT5_LIBDIR}, thereby triggering both portage's QA-check die that I patched out for testing as above, and the sanity check in the qtwebengine ebuild, which it appears I'll have to test-patch down to a warn to get the install done and actually run-time and downstream-dep-build-test the beta as well. But I haven't (yet?) dived into the qt build system to figure out why it's bugging out; where is it wrongly detecting the live canonical path instead of using the settings its given and what to do to fix it?
Two update points since I was reviewing old still open bugs and then came across point #1 only about an hour later while working on a different bug: 1) This bug was very likely triggered by "relocatable qt", as described in https://www.qt.io/blog/qt-is-relocatable Starting with qt 5.14 (of which I was running a beta at the original report) qt can be built anywhere, and by default will look for all its components in two places: 1a) Where the executable is (useful for MS and other common lib-bundled-with-executable platforms). 1b) Where qtcore is found. I asked earlier why the bug only appeared with 5.14-betas, not earlier versions. The relocatable-qt intro in 5.14 is unlikely to be coincidence, and this qt 5.14-beta would have been the first one finding qtcore in my reverse-usrmerged /lib64 (either before looking in the symlinked /usr/lib64 or resolving the /usr -> . symlink to canonical path) and then using that path in later-built modules. 2) Given that I'm still running with the local patches I was forced to apply to get 'round the bug as mentioned in comment #3, I'm unsure if the bug still exists with my current qt 5.15.0 or not. I could of course check, but given it's nearing a year and multiple qt updates without even a comment since the bug was assigned to qt, not bothering unless/until someone decides it's worth further investigation, at which point I can check with a then-current qt, seems prudent.
I certainly don't have any ideas regarding this at this time, but it might be worth noting that with Qt 6 the build system is changing to CMake, so indeed, whether or not this issue is still there with 5.15 might be at least somewhat irrelevant, unless of course it also happens with Qt 6 still. At least it doesn't seem very widespread since no one else has commented or reported it still. One can hope that it has been quietly fixed. :]
I've ran into this as well with dev-qt/qtdeclarative-5.15.10-r2::gentoo. My setup links /usr/lib -> /lib.
(In reply to Duncan from comment #4) > Given that I'm still running with the local patches I was forced to > apply to get 'round the bug as mentioned in comment #3, I'm unsure if the > bug still exists with my current qt 5.15.0 or not. (In reply to Vic Kerr (wikky) from comment #6) > I've ran into this as well with dev-qt/qtdeclarative-5.15.10-r2::gentoo. My > setup links /usr/lib -> /lib. I guess that answers /that/ question: Yes it still exists. But given... (In reply to Chiitoo from comment #5) > with Qt 6 the build system is changing to CMake, so indeed, whether or not > this issue is still there with 5.15 might be at least somewhat irrelevant ... We're certainly in "soon to be irrelevant" territory, particularly since kde/plasma is scheduled to do their irst qt6 release in February (previews starting in Dec IIRC), after which qt5 will likely go irrelevant pretty fast, altho it'll probably be another six months before full tree cleaning. Given the limited remaining time and that it has apparently only affected two people, both of which have done a "you're somewhat on your own with this" reverse-usrmerge (at least for /usr/lib(64) -> /lib(64)), it's likely not worth fixing at the gentoo level. The question then becomes... do you (VK) want me to post the patches I've used as workarounds? No use duplicating my work unnecessarily, but if you have other options and aren't going to pursue this further or in fact have already done your own patches...
(In reply to Duncan from comment #7) > (In reply to Chiitoo from comment #5) > > with Qt 6 the build system is changing to CMake, so indeed, whether or not > > this issue is still there with 5.15 might be at least somewhat irrelevant > > ... We're certainly in "soon to be irrelevant" territory, particularly since > kde/plasma is scheduled to do their irst qt6 release in February (previews > starting in Dec IIRC), after which qt5 will likely go irrelevant pretty > fast, altho it'll probably be another six months before full tree cleaning. Plenty of Qt5 consumers still remaining, I don't see it getting treecleaned anytime soon. > Given the limited remaining time and that it has apparently only affected > two people, both of which have done a "you're somewhat on your own with > this" reverse-usrmerge (at least for /usr/lib(64) -> /lib(64)), it's likely > not worth fixing at the gentoo level. I think I've come across a few more people with a similar setup. > The question then becomes... do you (VK) want me to post the patches I've > used as workarounds? No use duplicating my work unnecessarily, but if you > have other options and aren't going to pursue this further or in fact have > already done your own patches... Sure. I'll post mine.
Created attachment 896451 [details, diff] sys-apps/portage patch to ignore the /lib/*.a policy
(In reply to Duncan from comment #7) >> Given the limited remaining time and that it has apparently only affected >> two people, both of which have done a "you're somewhat on your own with >> this" reverse-usrmerge (at least for /usr/lib(64) -> /lib(64)), it's likely >> not worth fixing at the gentoo level. > >I think I've come across a few more people with a similar setup. To add to this (and this is my own view only): The whole point of the usr-merge is to make /lib and /usr/lib (etc) be the same directory. The world seems to be moving in the direction of merged-usr and split-usr is probably going to end up neglected and eventually deprecated as excess maintenance burden. Once only merged-usr is officially supported, policies like the one that triggers this issue are going to be pointless. It would be excess complexity to differentiate merged-usr and split-usr here but once split-usr inevitably goes away, it will make sense to review the paths policies. In a merged-usr system, it doesn't matter whether a file is installed in /lib or /usr/lib, same with e.g. /sbin or /usr/bin - they are the same directory, respectively.
Created attachment 896458 [details, diff] sys-apps/portage patch to change the /lib/*.a policy die -> ewarn (In reply to Vic Kerr (wikky) from comment #9) > Created attachment 896451 [details, diff] [details, diff] > sys-apps/portage patch to ignore the /lib/*.a policy I patched the same area but was a bit more minimal. I just made the static libs check non-fatal, die -> eqawarn. (JED are my initials. Tagged as not-intended for upstreaming as-is should I come across the code in another context.)
(In reply to Vic Kerr (wikky) from comment #8) > (In reply to Duncan from comment #7) > > > The question then becomes... do you (VK) want me to post the patches I've > > used as workarounds? > > Sure. I'll post mine. BTW, out of scope for this bug as it's nothing qt related, but I have had to do a few additional patches, the most recent to the new profile 23.0/profile.bashrc blind-test for /bin as a symlink (presumably to /usr/bin tho it doesn't test the target, thus the "blind"), while here it's /usr that's the symlink ( -> .) and /bin is the canonical location. So I basically appended an || -h /usr to the test. Of course the built-in /etc/portage/patches mechanism doesn't support patches to ebuilds/eclasses/profiles... but I have analogous /etc/portage/patches.ebuild functionality for the first two and just extended it with /etc/portage/patches.arbpatch to cover profile or other misc repository-file patching, so after ensuring that the relative path prefix is appropriate I can just drop it in the appropriate subdir and it gets auto-applied to updates just as /etc/portage/patches files do. I also had to patch the rust ebuild... well, it's a sed as my patches.ebuild mechanism supports that, simply s/usr\///g. That's probably overkill as I doubt /all/ /usr references in the ebuild need deleted, but it works. (Well it did last I used it; it could have bitrotted as I'm temporarily using the rust-bin ebuilds until I upgrade my decade-old amd fx6100 system... I've actually had the money in the bank for a 64-core/128-thread quarter-TB RAM threadripper for a year now, but turns out between actually kinda liking the security of having that in the bank and still needing to arrange more appropriate receiving for a shipped >$10K system, I've not actually pulled the trigger on the purchase yet.) And the systemd ebuild needed patching for awhile, but with upstream only supporting merged-usr now and the 23.0 gentoo systemd profiles enforcing it as I described patch ||-appending above, the systemd ebuild dropped that test so it no longer needs patched. But all in all that's surprisingly few patches given the deeply-assumed condition we're patching for, really demonstrating how flexible the general system actually is. =:^) If you (or anyone else, thus this public comment as opposed to directly emailing you this otherwise unrelated discussion) is interested in those patches, I guess I could either email them directly or we could do other bugs for them. (If requesting via direct email, please keep emails to plain-text if possible, as I filter html posts as spam and may not catch them in the trash.)
(In reply to Duncan from comment #12) > I have had to > do a few additional patches, the most recent to the new profile > 23.0/profile.bashrc blind-test for /bin as a symlink On that note - that check should really just compare realpaths, like so: - if [[ -h "${EROOT%/}/bin" ]] ; then + [[ "$(realpath "${EROOT%/}/bin")" == "$(realpath "${EROOT%/}/usr/bin")" ]] echo -n merged else echo -n split fi The existing check is crude and wrong, it'll say 'merged' when $EROOT/bin is a symlink to anything and 'split' if $EROOT/bin is a regular file. This one-liner patch isn't solid, either. The __gentoo_get_disk_splitmerge function needs refactored.
