The KDE 3.1 beta ebuild will install kde into /usr/kde/3.1/... Seeing as many of us are using the beta now, it would be a good idea to update the /etc/make.globals file and add /usr/kde/3.1/share/config to the CONFIG_PROTECT line. It doesn't hurt anything to add it now, and it will prevent someone forgetting it when KDE 3.1 actually does release.
fixed, thanks for submission
Hannes, this is not the proper fix for this issue. CONFIG_PROTECT should be added to the /etc/env.d/??kde file so it will be modularly added to your environment.
Reassigning to danarmak
If this is the case why is this not the current operation of the /etc/env.d files? In fact, none of my current env.d files have CONFIG_PROTECT env vars. If we intend to use env.d in this manner, perhaps we should push an update to the ebuild that contains the env.d file for kde (kde-env?) and remove all the other kde-related settings in /etc/make.globals. We could put it in one of the other kde ebuilds (kde-libs has an env.d file), but doing so without bumping the version would fix nothing, and bumping the version would be a painfully long rebuild just for an env variable.
Well, it's our policy as of now. I've spoken to Seemant and he agrees. It really makes more sense too. I'll make new kdelibs revisions - no way around that, sorry - and give everyoe some time to be sure they've upgraded, then I'll remove the old settings from make.globals. Meanwhie ther will be duplicate sttings but that's not a problem. I'll keep this bug as a reminder to do the latter part eventually. I'll make & test the new revisions now, and commit them shortly. (Note that the 3.1_beta1 ebuilds don't have revisions because I'm lazy)
Oh and the next portage will be needed - 2.0.36 when it comes out - because CONFIG_PROTECT and ditto_MASKED needed to be added to specials{} in env_update. So upgrade before testing.
Oh, and I'll add /usr/share/config to CONFIG_PROTECT via the kde-env package.
I'll commit this once portage 2.0.36 is released with the necessary fixes.
Dan, I don't understand why these env vars have to be tied to the kdelibs package instead of kde-env or even kde-base. (Either of which can be upgraded w/o a 12 hour compile). I do understand the need to move this out of /etc/make.globals. Perhaps the best of both would would be to commit the change into [kdelibs/kde-env/kde-base] (w/o bumping the current revision) and then remove the entries in make.globals when there is a need to bump the ebuild revision. I just hate the thought of a 12 hour compile session across several machines just to get an environment variable.
Because to make them fully dynamic, we want each KDE to add its own locatio to CONFIG_PROTECT. Thus kde-env is ruled out because it's only one even when multiple KDEs are installed. kde-env is in charge of the kde apps in /usr, therefore it adds /usr/share/config to CONFIG_PROTECT. kdelibs not kdebase because you can have a kde installation without kdebase, but not without kdelibs. Besides kdebase takes me longer to compile than kdelibs anyway (??).
Committing new revisions of kdelibs and kde-env, with an RDEPEND on >=sys-apps/portage-2.0.36. Because of this it may not be approved for all archs right away, since some might be using older portage versions (?).
