kdelibs 3/kdebase 4 co-installable ?

[Sune Vuorela]

On 2007-10-15, David Faure <faure at kde.org> 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