$ sigil /usr/lib64/sigil/sigil: /usr/lib64/libQt5Core.so.5: version `Qt_5.14' not found (required by /usr/lib64/sigil/sigil) RDEPEND=" ... >=dev-qt/qtcore-5.12:5
Brief looking at sources did not reveal any lockage on specific Qt version, i assume that culprit is missing subslots
I compiled sigil on build server and it had qtcore 5.14 After that I installed that binary package with the command emerge -KG sigil on another manchine with qtcore-5.12 in the same SLOT="5" package manager didn't stopped at subslot mismatch and install was completed successfully. But installed program doesn't work.
That happened exactly because ebuild missing subslot operator
Firstly, I want to note that you are talking here about forward compatibility, and not backward (because you try to run Qt v5.14 on Qt v5.12). Based on Qt documentation, https://wiki.qt.io/Qt-Version-Compatibility, only backward is supported and not forward. Based on Gentoo documentation about sub-slotting, https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Subslots#What_do_subslots_represent.3F , the policy for Qt dependencies is to depend on sub-slot only in case private Qt API is used, which isn't used in Sigil. I viewed similar in Qt API usage packages in the Gentoo Tree, and haven't found packages that depend on Qt sub-slot. On the other hand, in case I add sub-slot dependency on Qt, it will cause needless rebuilds for users in every regular Qt upgrade, without any real need. I'm not sure about the Gentoo policy, but I don't think forward compatibility is supported. Please not I'm only proxy-maintainer, and if an official developer says otherwise, I will take his stand - I just want to state my concerns with just adding sub-slotting.
> you try to run Qt v5.14 on Qt v5.12 I just trying to run sigil. I don't care which version of Qt will be used. The only thing i wish, is the absence of broken software. Right now I was able to get nonworking install with portage. There is a difference between "sublot dependency" and "subslot operator". Now it is >=dev-qt/qtcore-5.12:5 sublot dependency will be >=dev-qt/qtcore-5.12:5/5.12 subslot operator will be >=dev-qt/qtcore-5.12:5= > it will cause needless rebuilds for users in every regular Qt upgrade, without any real need. I don't understand why it gives a message version `Qt_5.14' not found (required by /usr/lib64/sigil/sigil) who exactly write this message and why. > only backward is supported and not forward. broken software install is not the solution. Portage should install binary version of qt-5.14 during the install of sigil. I believe that this is a problem, which should be solved one way (fixing ebuild, or patching sigil) or another (fixing portage).
Point taken - we can not provide forward compatibility if Qt upstream does not do it. Also, maintainer can not be forced to add subslot here, because of specific expection, granted by QA team docs regarding Qt libraries subslotting. So, let's summarize - if you find that binary packaged app-text/sigil, built with Qt version 5.x is broken on system with installed Qt version 5.y, where y>x, than - feel free to reopen this bug.
