We need lots of non-git ebuilds :) Reproducible: Always
And maybe it's time to introduce the category kde-applications along with this release?
I would like to help creating ebuilds for this release. But I don't know how you would like this to be done. Since this is a mixed release (having both KF5 and kdelibs4 based applications), we will need to consider a few things. Will the SLOT be the major version of the library they use, which means programs of the same release will have two possible SLOTs? Or should we get rid of the SLOTs for kde-applications? This would make sense since this is basically what the KDE by decoupling their applications release from the release of the underlying libraries and making mixed releases. Also, while different versions of libraries are meant to be co-installable, versions of the same applications are not, which would require us to use a blocker in all ebuilds when SLOTs are used. On the other hand, SLOTs would be an easy means for users to know prior to installation what libraries an applicaton will use. What eclass will we use in the ebuilds? The easiest way is probably to extend the kde4-base and kde5 eclass and use those to distinguish between library versions. Or we could introduce a kde-applications eclass and distinguish based on SLOT or some KDE_LIBRARY_VERSION variable. If this discussion is already going on elsewhere, I would like to know where. I couldn't find anything.
There's been bits and pieces of discussion (mostly on #gentoo-kde) but nothing substantial. There's a discussion regarding category started on our mail alias, but that's subject to team approval and any new categories need to be approved by the community too. There seems to be general agreement that it makes sense to have separate categories for Plasma and Applications though. Regarding slotting, there's obviously pros and cons of both. I tend to think it's better to enforce uniform SLOT of 4/5 for consistency, as well as minimising the chance of breakage with a Qt4 package trying to use a Qt5 library etc. No consensus has yet been reached on new or existing eclass either. If you have ideas/opinions on how things should be handled, now is the time to share. :-) FWIW, I'll be pushing a branch to the overlay to show my ideas.
If you could just push your current progress (changes to eclasses, a few ebuilds of both KF5 and KDElibs4 based applications, that'd be great. I'd be happy to make more ebuilds for KF5 based applications. I just got rid of KDElibs4 the other day. I think a kde-applications eclass that handles things like SRC_URI, EGIT_BRANCH could be useful. It may also, based on SLOT or some other variable determin the required library version.
I'm currently working in https://github.com/gentoo/kde/commits/apps-scratch It's basically completely untested (I just finished build ebuild renames), but kde-apps/kcalc, oxygen-icons, and libkeduvocdocument should be OK. My idea keeps (so far) ebuilds basically the same as now, and we can bump from the live ebuilds as normal. That would require somehow keeping track of *which* live ebuild to bump from though - such as a hard-coded list in a bump script, or some convention like "9999 is upstream master/release, and 5.9999 for packages with unreleased frameworks branches".
So far kate, gwenview and konsole are tested and working. kde-apps/dolphin needs a dependency adjustment: it now should depend on kde-apps/libkonq, rather than kde-base/libkonq. Also, all kde-apps packages should get blockers for their kde-base pendants, since KDE4 will probably stay in kde-base and stick around for a while.
kde-apps/khangman and kde-apps/kanagram also need dependency adjustments to kde-apps/libkeduvocdocument. parley, kalgebra and kapptemplate need KF5 ebuilds. okteta segfaults: QIODevice::read: device not open Icon theme "oxygen" not found. Icon theme "oxygen" not found. codecForName: ucnv_open failed ISO-8859-16 U_FILE_ACCESS_ERROR Segmentation fault
kde-apps/gwenview does not need kde-apps/libkonq. Also, this dependency is broken, because kde-apps/libkonq has not yet been released for KF5.
any -meta packages should not be slotted at all, at least not when they have dependencies on both KF5 and KDElibs4 based applications. Here, slotting really doesn't make any sense. SLOT could be overridden to "0" or maybe this calls for introduction of a kde-apps eclass. I guess you will know best.
Created attachment 390542 [details] kde-apps/parley-14.11.97 khangman, kanagram and their dependencies work. Parley needs some dependency adjustments (tested and working ebuild attached).
Which oxygen-icons do you have? I had a file collision between parley and oxygen-icons:5.
(In reply to Malte E. from comment #9) > any -meta packages should not be slotted at all, at least not when they have > dependencies on both KF5 and KDElibs4 based applications. Here, slotting > really doesn't make any sense. > SLOT could be overridden to "0" or maybe this calls for introduction of a > kde-apps eclass. I guess you will know best. Is there any benefit from SLOT=0 compared to SLOT=5? SLOT=5 indicates that at least one package depends on kf5. This helps us to see which packages can be unmasked, after we moved kde-apps to the tree (because qt5 is still masked). Users that want to stay with kde4, can install kde-apps/*meta:4 plus kde-base/*meta:4. If there is any need for, we might introduce further kde-apps/*meta:4 (blocking appropriate kde-apps/*meta:5) packages for users who want to stay with kde4, that depend on the appropriate kde-base/*meta:4[minimal].
@kensington: I don't have oxygen-icons installed at all.
Parley is done, and I've added a wiki page to track the KF5 ports still todo: https://wiki.gentoo.org/wiki/Project:KDE/Frameworks/Applications
