Created attachment 451692 [details, diff] pinentry-0.9.7-r2.ebuild.diff Many lines slashed by removing Qt4 and bumping to EAPI 6. Sorted USE, DEPEND, and config options.
Thanks! Why are we dropping qt4? Minor comments: 1. you must leave: if use qt5; then export MOC="$(qt5_get_bindir)"/moc export QTLIB="$(qt5_get_libdir)" fi 2. why do you "${ED%/}"?
(In reply to Alon Bar-Lev from comment #1) > Thanks! > > Why are we dropping qt4? I haven't decided yet whether it is a good thing, but Qt team is pushing for it > 2. why do you "${ED%/}"? to avoid double-slashing
> 1. you must leave: > if use qt5; then > export MOC="$(qt5_get_bindir)"/moc > export QTLIB="$(qt5_get_libdir)" > fi Didn't seem to be necessary for me during testing, but I can add it back. (In reply to Alon Bar-Lev from comment #1) > Why are we dropping qt4? Imo Qt5 is working sufficiently well at this point and there is no reverse-dependency left that would explicitly depend on pinentry[qt4]. For reference: https://wiki.gentoo.org/wiki/Project:Qt/Policies#Handling_different_versions_of_Qt Putting this out there but no rush. If there's a new release in sight it may be applied with that bump.
In case you were wondering, while there are plenty other Qt4 packages at this point - Plasma-4 removal coming soon -, I've been specifically looking at packages with REQUIRED_USE hardship first.
(In reply to Kristian Fiskerstrand from comment #2) > (In reply to Alon Bar-Lev from comment #1) > > 2. why do you "${ED%/}"? > > to avoid double-slashing It is not damaging anything... we don't add it anywhere... and if important portage should do this globally. (In reply to Andreas Sturmlechner from comment #3) > > 1. you must leave: > > if use qt5; then > > export MOC="$(qt5_get_bindir)"/moc > > export QTLIB="$(qt5_get_libdir)" > > fi > > Didn't seem to be necessary for me during testing, but I can add it back. These are a must to disable the auto-detection and make sure that you are using the right qt. > (In reply to Alon Bar-Lev from comment #1) > > Why are we dropping qt4? > > Imo Qt5 is working sufficiently well at this point and there is no > reverse-dependency left that would explicitly depend on pinentry[qt4]. For > reference: > https://wiki.gentoo.org/wiki/Project:Qt/ > Policies#Handling_different_versions_of_Qt > > Putting this out there but no rush. If there's a new release in sight it may > be applied with that bump. pinentry has no dependency for explicit interface anyway, I do not thing having qt4 is an issue as long as it is working and does not add extra maintenance efforts.
> > > > Putting this out there but no rush. If there's a new release in sight it may > > be applied with that bump. > > pinentry has no dependency for explicit interface anyway, I do not thing > having qt4 is an issue as long as it is working and does not add extra > maintenance efforts. exactly
(In reply to Alon Bar-Lev from comment #5) > pinentry has no dependency for explicit interface anyway, I do not thing > having qt4 is an issue as long as it is working and does not add extra > maintenance efforts. It is adding maintenance efforts for every user having USE="qt4 qt5" (which is the common case right now). The plasma profile has piled up many lines of solving such REQUIRED_USE conflicts, but not everyone is using (or even can use) it. In cases like vlc, where there are some known issues with the Qt5 implementation, one can make the qt5 flag simply override qt4 if both are set, but some devs will call that an ugly solution. If there is no known issue, there is no reason to keep qt4, especially when there is no Qt4-based desktop left in tree (soon).
Created attachment 452420 [details, diff] pinentry-0.9.7-r2.ebuild.diff Added back QTLIB and MOC lines.
(In reply to Andreas Sturmlechner from comment #7) > (In reply to Alon Bar-Lev from comment #5) > > pinentry has no dependency for explicit interface anyway, I do not thing > > having qt4 is an issue as long as it is working and does not add extra > > maintenance efforts. > > It is adding maintenance efforts for every user having USE="qt4 qt5" (which > is the common case right now). The plasma profile has piled up many lines of > solving such REQUIRED_USE conflicts, but not everyone is using (or even can pinentry is... > use) it. In cases like vlc, where there are some known issues with the Qt5 > implementation, one can make the qt5 flag simply override qt4 if both are > set, but some devs will call that an ugly solution. If there is no known > issue, there is no reason to keep qt4, especially when there is no Qt4-based > desktop left in tree (soon). qt5 support is relatively new upstream, and qt4 is mostly recommended still, not to mention the c++11 mess of qt5.7 that gentoo devs push under a rug with in-ebuild magic instead of fixing it upstream
Well, to be fair some upstreams just tell you to use >=GCC-6 'so it will work anyway' ;) It's not like pinentry[qt4] would be going away soon, there are plenty older versions to choose from - and alternatively, gtk+2. And as I said, if this is done only for 0.9.8, I'm happy enough.
(In reply to Andreas Sturmlechner from comment #10) > Well, to be fair some upstreams just tell you to use >=GCC-6 'so it will > work anyway' ;) Thats nonsense > > It's not like pinentry[qt4] would be going away soon, there are plenty older > versions to choose from - and alternatively, gtk+2. And as I said, if this > is done only for 0.9.8, I'm happy enough. I'm not removing qt4 until bug 589412 is fixed properly c.f comment 4: "Even better, patch the build system (and code if it fails to build in c++11 mode) and send the resulting patch upstream. Note that some programs use GNU extensions, in that case -std=c++11 becomes -std=gnu++11. Ultimately, this in an upstream problem, so make sure you at least report the issue to them (and apply a workaround downstream asap while you wait for the official fix)."
So, how about qt5 overrides qt4 if both are set?
(In reply to Andreas Sturmlechner from comment #12) > So, how about qt5 overrides qt4 if both are set? explicit is always better than implicit, avoid ambiguity for auditing purposes etc, and it causes needless complexity in dependency specification
Created attachment 455810 [details, diff] pinentry-1.0.0-r1.ebuild.diff Patch update to 1.0.0.
Created attachment 495144 [details, diff] pinentry-1.0.0-r1.ebuild.diff One year later and we are removing Qt4 left and right.
(In reply to Andreas Sturmlechner from comment #15) > Created attachment 495144 [details, diff] [details, diff] > pinentry-1.0.0-r1.ebuild.diff > > One year later and we are removing Qt4 left and right. Yeah, now I'm fine with removing qt4 support in principle, however can you please provide a git format-patch for the change including a properly formatted commit message, and limit the changes to the minimum set required, the reordering of deps etc is noise in review and not necessary for the bump, in particular removal of specific minimum versions is likely counter-productive.
(In reply to Kristian Fiskerstrand from comment #16) > (In reply to Andreas Sturmlechner from comment #15) > > Created attachment 495144 [details, diff] [details, diff] [details, diff] > > pinentry-1.0.0-r1.ebuild.diff > > > > One year later and we are removing Qt4 left and right. > > Yeah, now I'm fine with removing qt4 support in principle, however can you > please provide a git format-patch for the change including a properly > formatted commit message, and limit the changes to the minimum set required, > the reordering of deps etc is noise in review and not necessary for the > bump, in particular removal of specific minimum versions is likely > counter-productive. By all means, we can do the sorting as well, but it should be in a separate, atomic commit.
(In reply to Kristian Fiskerstrand from comment #16) > in particular removal of specific minimum versions is likely > counter-productive. Only if supporting pre-gitmigration systems is your thing.
(In reply to Andreas Sturmlechner from comment #18) > (In reply to Kristian Fiskerstrand from comment #16) > > in particular removal of specific minimum versions is likely > > counter-productive. > Only if supporting pre-gitmigration systems is your thing. If we know of build system dependency constraint we apply this constraint, it provides seamless upgrade and easier problem determination. It has nothing to do with the format portage is stored in.
git migration hints at a certain point in time, but I'm sure you knew that... it's not like I'm insisting, anyway.
Created attachment 495468 [details, diff] the road to pinentry-1.0.0-r1.ebuild
Created attachment 495470 [details, diff] the road to pinentry-1.0.0-r1.ebuild
thanks, pushed.. e07243ace7efe6d5263f34926ff9527f24af4dca (HEAD -> master, origin/master, origin/HEAD) app-crypt/pinentry: Revbump for patch series to remove qt4 etc e2aca68589cabc261e6be6d41a5e714d5b7e0abe app-crypt/pinentry: Add missing dependency dev-qt/qtcore:5 afd0a92aa9e98c1f819f196005954d4d0ff34235 app-crypt/pinentry: Remove unused multilib.eclass 58cf86d2249678a4a92401a3eb8d2e79a2bfbaa5 app-crypt/pinentry: Switch HOMEPAGE to https 23020e14b68c739d73a377ae952017d3304a3fd4 app-crypt/pinentry: Sort IUSE and DEPENDs ac9d567f1e2457315d5eea1c60b35e5fec6c424e app-crypt/pinentry: Drop USE=qt4
