On 2007-10-15, David Faure wrote: > But wait, how did the share/icons/* conflict get solved? AFAIK kdelibs3 and kdelibs4 + kdebase4-runtime > all install into share/icons/*... > Does this work simply because the default icon theme has changed? I have actually no memory of how this were resolved. Looking at it, it looks like a combination of pure luck and the changed default theme. - changed themes => different default path - pure luck => the crystalsvg files in kde4base isn't in kde3libs But I guess there might be problems with kde5. But then again, that might be time to EOL oxygen at that time? > (A solution could be to have a shared package that both kdelibs3 and kdebase4-runtime depend on, > but I can see how that makes the life of packagers complicated, for just some pngs... > and it also assumes the default theme hasn't changed...) This solution could be applied from packagers point of view, but as you notice yourself it has some drawbacks. > Ah there's the better solution: renaming the default theme to "kde4". Then it won't conflict, and it can > coexist with existing themes from kde3 and kde-look. We just need to find the code which hardcodes > "Default". > I like this solution :) I think it sounds reasonable. Maybe except for the "find the code" part. "Default" isn't actually easy to grep on, but probably the use of *urgh* emoticons is limited to kopete, konversation and maybe kmail. >> > /usr/bin/imagetops >> >> seems to be used in a desktop and a xml file under >> kdebase/runtime/kdeprint/filters/ >> and in kdebase/runtime/kdeprint/kdeprintfax/faxfilters > > Hmmpf. This is part of the deprecated framework that is soon going to be removed from compilation I assume? > (This isn't a question for you, but for the kdeprint guys :) Removing it all together seems like a solution. it is also easy to patch it if there is a need to still keep it around. > >> > /usr/bin/kcmshell >> >> used around 40-50 places in the code or so - and in a insane amount of >> desktop files > Yep. Fixed. thank you. > >> > /usr/bin/kfile >> >> can't any trace of this actually being used as a command anywhere? > Yep, just an end-user tool. Renamed to kfile4; distros can always add a symlink > when kdelibs3 is not installed I suppose (e.g. using the "alternatives" mechanism). Yeah. we can ship appropriate symlinks there when/if it becomes relevant. >> > /usr/bin/kdostartupconfig >> seems to just be launched from different places inside kstartupconfig. >> > /usr/bin/kstartupconfig >> Seems to just be used in the startkde script. > Yep. Renamed. nice. >> > /usr/bin/khotnewstuff >> can't find any references to where this is used as a program. > Thanks for checking, I wasn't sure. It's an end-user program then. Renamed. > >> > /usr/bin/ksvgtopng >> >> seems like not used at all? or is it actually something that could be >> moved to -dev packages? Even though it is in kde4 in kdebase/runtime > > I have no clue about this. lxr says playground/multimedia/jukquiz/pics/Makefile.am was calling it, > but that's it. So it sounds like an artist's tool; this is also what I thought > when moving it to kdebase/runtime, but now I see your point, there's no -dev > for a collection of helper binaries like kdebase/runtime :) > Hmm, now what? Renaming it is the easy way out I guess. we can stuff the file together with the dev headers of kdebase, but maybe renaming it is a bit cleaner. >> in general it at least looks easier than I expected. > Yes it's easy ... when you don't do it yourself :-)) Hehe. well.. I don't have commit access - and most of these changes it is I think as easy to change it self as it is to look over patches. /Sune