Summary: | Move kde env.d settings from (arts+kdelibs) to kde-env[-slotted] | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nilton Volpato <nilton> |
Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | aoyu93, betelgeuse, bluedrago, brad, expose, frbiscani, gg.alex.weiss, jakub, kavol, luca.botti.gentoo, m.debruijne, ravi, sapphireswan, syscon780, thomasvk |
Priority: | Highest | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Nilton Volpato
2005-08-29 12:52:08 UTC
Suggestion: put this in kde-base/kde-env, instead. Running into this also. Let's move that file into the kde-env ebuild. /etc/env.d/46kdepaths-3.4 is installed by kdelibs if -arts is in your USE flags, and so will be created by either arts or kdelibs depending on your USE flags. Just double checked and this works on my system - a file collision is generated due to my system being built with arts already. Do you guys have USE=-arts set globally? Ok, i found out that my kdelibs was installed with +arts and the other packages with -arts. But why not to move this to kde-env anyway? Wouldn't this be better, and avoid such problems? The reason this isn't in kde-env is that kde-env has only one ebuild version/slot. It sets settings like KDEDIRS=/usr, needed for all kde versions. The settings in 46kdepaths-3.4 are per KDE slot (3.4 in this case) and so should be moved to a new ebuild called eg 'kde-env-slotted'. Or we could have multiple slots of kde-env, but version 3 being slot "0" (as it is now) is then a bit counterintuitive. Doing this is a good idea, to prevent cases where adding or removing arts to USE leaves a system with either double ownership of 46kdepaths-3.4 of (worse) without 46kdepaths-3.4 being installed at all. (Yes, such a system would be broken in other ways and/or should be fixed on emerge world.) I remember it being proposed before but getting stuck for some reason. Possibly merely due to the 'it works, don't touch it' syndrome. *** Bug 107612 has been marked as a duplicate of this bug. *** *** Bug 86748 has been marked as a duplicate of this bug. *** *** Bug 109698 has been marked as a duplicate of this bug. *** *** Bug 110053 has been marked as a duplicate of this bug. *** *** Bug 128245 has been marked as a duplicate of this bug. *** *** Bug 128740 has been marked as a duplicate of this bug. *** Ping here, this should really be fixed before KDE 3.5.2 goes stable... *** Bug 125141 has been marked as a duplicate of this bug. *** *** Bug 141109 has been marked as a duplicate of this bug. *** Uhm, are you waiting for KDE4 here so that the issue dies with arts, or what? :P This is causing real breakage, as you can see from the dupes. run into it right now Slotting is not possible, since the ebuilds would conflict installing /etc/env.d/99kde-env both. The solution is not to install env data with the aRts ebuild. Should not be an issue, unless someone wants to run a standalone aRts server. Sorry, not supported. Finally fixed with arts-3.5.4-r1. And where is 45kdepaths-3.x gone now? I emerged arts-3.5.4-r1 and kdelibs-3.5.4-r1 and now this file is no longer in /etc/env.d/ which gives me many headaches as all kde-paths are away now :-( Because you use ~arch and aRts, while I don't. I missed to remove the if ! use arts ; then fi block around the relevant lines. Fix is in cvs. Sorry. I know that I'm using ~arch :) Alright I just sent you an email about this issue but I think this mail can go its way to /dev/null now :) Thanks for fixing this so fast. I just installed a fresh ~x86 system with a tree from yesterday and I don't have an env-file with kde paths. After an emerge --sync I don't have any kde update so I assume the error has been corrected without a rev-bump. Could someone be so nice to tell me what ebuild now contains the correct env-file? A better solutions off course would be a revbump to push this fix to all ~arch users who now have a broken kde. Thanks! Michiel: emerge kdelibs again - or populate the file yourself (see bug 144917), with the downside that you'd have to emerge kdelibs with FEATURES=-collision-protect next time. Thanks Carsten, for your reply and the great work you do for KDE/Gentoo. *** Bug 145150 has been marked as a duplicate of this bug. *** *** Bug 145163 has been marked as a duplicate of this bug. *** *** Bug 145172 has been marked as a duplicate of this bug. *** *** Bug 147883 has been marked as a duplicate of this bug. *** |