subj. my ebuilds are in rion-overlay Reproducible: Always
See also https://github.com/gentoo/qt/blob/master/app-crypt/qca/qca-9999.ebuild
Probably we need ebuilds similar to those in the rion overlay so that we have a co-installable QCA. But as there is not fixed suffix for the Qt5 version of QCA (or for Qt4) if we want to make it co-installable, we need to select a QCA_SUFFIX and also add it to *all the reverse deps*. The easier solution for QCA packaging would be to dismiss co-installability and just use make either Qt4 or Qt5 available. This solution will lead though to problems with the co-installability of Qt4 and Qt5 apps that both use QCA (probably already inside the KDE Apps 14.12 bundle).
An upstream solution that can be shared by all distros would be preferable. Co-installability of qt4 and qt5 versions sounds like a worthy goal in this case.
This will probably not happen, see the discussion in https://git.reviewboard.kde.org/r/119939/
TS at https://git.reviewboard.kde.org/r/119939/ is kinda an idiot or something. current git qca has everything required to have binaries for qt4 and for qt5 on the same system. binaries have different names, different pkgconfigs and different cmake modules scripts. another question is standard suffix for all 3rdparty libraries depending on Qt. or maybe special installation location for them when possible.
That was never the problem - anybody can make anything coinstallable. How do you expect consumers to be able to find the library with some random suffix?
>> How do you expect consumers to be able to find the library with some random suffix? it's not related to https://git.reviewboard.kde.org/r/119939/ bug I'm agreed. gentoo qt team should decide how to split qt based libraries. if it's suffix then what exactly etc. currently qca allows to choose suffix via cmake argument. also it's possible to install qca libs to Qt prefix (cmake detects if automagically)
What are you talking about? We're not deciding on any suffix or entertaining any other such nonsense suggested by upstream. If upstream cannot provide something sane where finding the appropriate Qt4/Qt5 Qca variant just works, we're not interested.
it's already sane
Please provide example then of how to build Qca for both Qt4 and Qt5, and have consuming packages find the appropriate version automatically.
I've added *experimental* multibuild support in the overlay using the same suffix as Kubuntu (note that zero Qt5 revdeps will build without modification). We should wait until the upstream situation is resolved before bumping.
(In reply to Michael Palimaka (kensington) from comment #11) > We should wait until the upstream situation is resolved before bumping. Agreed.
Created attachment 394110 [details] mail.txt Mail from Harald Sitter <sitter@kde.org> on upstream mailing list.
@qt i"ve made a version bump based on your 9999 version in kde overlay. It enables multibuild based on the patched release mentioned in mail.txt. The test phase has one test which prompts for an gpg passphrase (a) we need to find out how to feed it properly b) patch this test case out c) restrict all). Have fun :)
@kde, feel free to sync the live ebuild in the qt overlay, and to move 2.1.x to the tree, if appropriate.
(In reply to Davide Pesavento from comment #15) > @kde, feel free to sync the live ebuild in the qt overlay, and to move 2.1.x > to the tree, if appropriate. The doc use flag needs to be fixed first. And i realy dont know if the patched changes in tarball made it into the git master branch.
(In reply to Johannes Huber from comment #16) > (In reply to Davide Pesavento from comment #15) > > @kde, feel free to sync the live ebuild in the qt overlay, and to move 2.1.x > > to the tree, if appropriate. > > The doc use flag needs to be fixed first. And i realy dont know if the > patched changes in tarball made it into the git master branch. I think Harald's email in the kde-frameworks mailing list said that changes will never make to the git master branch because the maintainer opposes them. This patched tarball was seen as the compromise to resolve the situation. If you look at the qt5 branch in the repository then even there you can see reverts and reverts of reverts...
(In reply to Andrius Štikonas from comment #17) > (In reply to Johannes Huber from comment #16) > > (In reply to Davide Pesavento from comment #15) > > > @kde, feel free to sync the live ebuild in the qt overlay, and to move 2.1.x > > > to the tree, if appropriate. > > > > The doc use flag needs to be fixed first. And i realy dont know if the > > patched changes in tarball made it into the git master branch. > > I think Harald's email in the kde-frameworks mailing list said that changes > will never make to the git master branch because the maintainer opposes > them. This patched tarball was seen as the compromise to resolve the > situation. If you look at the qt5 branch in the repository then even there > you can see reverts and reverts of reverts... The maintainer who didnt want the co-installable feature left the project of that reason. So it will hit the master branch at some point.
Thank you for reporting. This is fixed in tree. Masked until i have the reverse dependencies fixed. + + 28 Jan 2015; Johannes Huber <johu@gentoo.org> + +files/qca-disable-pgp-test.patch, +qca-2.1.0.3.ebuild, metadata.xml: + Version bump, bug #528620. +
johu, did you see my comments on your commit on github? https://github.com/gentoo/qt/commit/e4d722445edfea16ba9c99844304ce72e40b3794
