Here they are as discussed in bug 25013. They are grouped by category; for now I send just the first ones so you can tell me if you prefer a different style. In particular, these patches modify all the ebuilds (not just the latest stable and unstable) and also the ebuilds that were not broken (those without DEPEND and RDEPEND), for consistency and because it was easier for me, but you may have a different opinion... just let me know. Note that even after these modifications the ebuild that set DEPEND but not RDEPEND are still broken. We need a patch to kde-functions.eclass so that RDEPEND is filled only if it was not unset. Something like the first patch submitted.
Created attachment 31153 [details, diff] kde-functions.eclass.patch
Created attachment 31154 [details, diff] app-arch.kde-need.patch
Created attachment 31155 [details, diff] app-cdr.kde-need.patch
Created attachment 31156 [details, diff] app-crypt.kde-need.patch
This bug is becoming slightly obsoleted now. However, please take a look just at the first patch and see if that can have some benefits. After that, I can close this bug for now.
discussion taking place at bug 58819
The patch to kde-functions.eclass doesn't handle the case where an ebuild first calls need-kde and then sets RDEPEND. What choices have we got? 1. Change all non-kde-base ebuilds to use eg $NEED_KDE. A lot of work, even if we script it. Not fun. 2. Use E_RDEPEND in need-kde(). It isn't a public portage interface, so things can break one day. Therefore not fun. 3. Use the attached patch and make sure all ebuilds call need-kde after setting DEPEND/RDEPEND if any. That's less work than (1), but it's a rule that'd be very easy to break without noticing in the future. To protect against this, we could change need-kde() to die if DEPEND/RDEPEND is already defined. That's not very pretty. Opinions? As you can notice, I don't like any of these options ;-(
A point for option 3 is that ebuilds setting need-kde before {R}DEPEND are considered broken even right now, because if the ebuild writer later forgets to use DEPEND="${DEPEND} ..." instead of DEPEND="..." the ebuild will be screwed up. So, nearly all the ebuilds were changed over time to have need-kde after DEPEND. I just grep'd the whole tree to search for ebuilds still having need-kde before DEPEND, and there were only half a dozen, so I took some time to fix them a few minutes ago. Now at least the most recent version of each ebuild should be correct (funnily, kdebase-startkde showed up as using need-kde, is there a reason for that?). From a more general point of view, I think in the future we will need to do a big cleanup of the eclasses setup (with kde4 as a target?) starting nearly from scratch, with the focus on having easy-to-use eclasses even for non-kde devs, and difficult to be used in wrong ways. (this could fit in the eclass/elibs pattern, too). From this point of view, using something like $NEED_KDE is probably the best way.
Then we can apply the patch as-is, and add the die statement as per option 3 to make sure noone breaks this accidentally later. Objections? I'm also wholly in favour of new, clean kde eclass - whether for kde4, or with GLEP33, or both.
About an extra check in need-kde: it should avoid DEPEND/RDEPEND being redefined _after_ need-kde, and I don't think it's possible ;)
I have the bit of code to allow a smooth transistion from need-kde to NEED_KDE here, so we wouldn't have to do it for all ebuilds at once. Just need to have a look at it and to update it a bit, since it doesn't take the splitted ebuilds into account. For the time being Gregorio's patch is fine, but I dislike it a lot, since it doesn't change the current way, calling a eclass function in the toplevel of the ebuild.
Is it ok to remove need-kde() from kdebase-startkde and to apply the patch for now?
Looks OK.
Comitted.
