When kdelibs is not installed using portage kde4-base.eclass fails to detect KDEDIR. This has the impact that if user installs KDE from (upstream) sources then all KDE related apps must also me custom installed. Suggest that kde4-base.eclass respects the env variable KDEDIR. Reproducible: Always Steps to Reproduce:
Should probably be guarded by I_KNOW_WHAT_IM_DOING=yes, otherwise it sounds like a bug-generator.
Ahem and why exactly we should support such setup? It leads to more issues lately...
Well considering that compiling KDE using the preferred upstream method (kdesvn-build) is way faster the using the ebuilds for a KDE developer it is rather annoying to use portage for KDE. But I do not want to roll all KDE related packages my self. Considering the fix is a quite simple.... replace KDEDIR= with [[ ${I_KNOW_WHAT_IM_DOING} -ne "yes" ]] && KDEDIR= in kde4-base.eclass and problem fixed.
And did you take into considering the users of live kde ebuilds? They can use the I_KNOW.. for stating that they dont want to get aditional informations and stuff, and with this you prossibly introduce hole into their system. If anything exports there KDEDIR they will get seriously fcked up system. Is kdesvn-build faster? also you can define overrides for svn repositories, so you can devel on your app and still use our live ebuilds.
How about I_PROMISE_NOT_TO_OPEN_A_SINGLE_BUG_REPORT_TO_GENTOO_EVER_NEVER_EVER? Seriously. WONTFIX.
Well, no need to resolve/WONTFIX it now imho. It could stay open, it's feature request after all and we may reconsider it some time later.
(In reply to comment #5) > How about I_PROMISE_NOT_TO_OPEN_A_SINGLE_BUG_REPORT_TO_GENTOO_EVER_NEVER_EVER? Not really called for. (In reply to comment #4) > Is kdesvn-build faster? also you can define overrides for svn repositories, > so you can devel on your app and still use our live ebuilds. kdesvn-build is much faster since it doesn't start from scratch each time (unless told to). When following trunk the need for starting over is seldom there but the need for recompiling is there quite often. This problem will not be fixed by defining an override for the svn repo. If I could get portage to rebuild without reconfiguring and wiping the build dir then I could use portage for developing KDE. Perhaps this is a more generic issue with portage?
It's my opinion that the purpose of the Gentoo KDE team is to support the installation of KDE using Gentoo tools - not to support custom made installs by users. If someone is an upstream dev for KDE and wants to build KDE by hand, then so be it, but don't expect the KDE team to support such a setup. Furthermore, the Gentoo KDE team currently provides, upstream releases (latest 4.3.2 and latest stable 4.3.1) in the tree, and current release snapshots (4.3.9999), next branch previews (4,3.[6|7|8|9]*) and live snapshots (9999) in the kde-testing overlay. I think we do enough already.
(In reply to comment #5) > How about I_PROMISE_NOT_TO_OPEN_A_SINGLE_BUG_REPORT_TO_GENTOO_EVER_NEVER_EVER? LOL :D > Seriously. > > WONTFIX. > +1
This one's gotta go. Now. We'll never get back to it anyway. :)
