[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kdelibs 3/kdebase 4 co-installable ?
From:       Sune Vuorela <nospam () vuorela ! dk>
Date:       2007-10-16 11:23:21
Message-ID: slrnfh97p9.ntj.nospam () sshway ! ssh ! pusling ! com
[Download RAW message or body]

On 2007-10-15, David Faure <faure@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


[prev in list] [next in list] [prev in thread] [next in thread]