[kde-solaris] dependencies for KDE (was: KBE)

[Adriaan de Groot]

On Friday 07 December 2007 21:55, Shawn Walker wrote:
> On Dec 7, 2007 2:21 PM, Alan DuBoff <alan.duboff at sun.com> wrote:
> > On Fri, 7 Dec 2007, Shawn Walker wrote:
> > > No, that argument for moving to /usr does not hold here. I'm fairly
> > > certain from the ARC cases (which I have been following with interest)
> > > that their reasoning does not apply here as they are things that Sun is
> > > distributing and is a completely different reasoning.
> >
> > Not in my mind. I don't see kde as being optional software, it's my
> > desktop. I would like it with the rest of my system, in /usr, just like
> > GNOME is on OpenSolaris. The only difference is that the community is
> > working on this.
>
> Yes, but then logically you would want to apply that to every other
> piece of third party software and then you have the problem of that
> third party software conflicting with what the vendor distributes.

Let's try to untangle the mess a little. We have the following kinds of 
dependencies:

- Build tools. These are specific to building the KDE software stack and are 
installed by kbe in /opt/kdebld. They don't really need to be used after the 
KDE stack is built. This part *does* include C++ applications like CMake, but 
they don't link against anything higher in the stack.

- C dependencies. This covers a whole range of libraries and tools. Looking at 
what is now in the Build/ part of cvsdude, this includes pcre, openexr, 
libungif, ... These C dependencies might be shared with other packages, don't 
suffer from ABI problems, and could, for instance, be installed 
in /opt/kdecdeps.

- C++ dependencies. This starts with RW stdcxx and moves upwards from there, 
and includes clucene, raptor, redland. There are fewer C++ dependencies than 
C dependencies, I think. These *are* tied to our choice of C++ STL. They 
might go in /opt/kdecppdeps.

- Qt I would, in this case, put under /opt/kdecppdeps as well. As Shawn points 
out, it is also tied to the chosen ABI and is incompatible with other 
choices, so it would be polite not to get in someone else's way.

- Then we get to actual KDE SVN modules. I would put these -- including the 
kdesupport module, which includes Strigi, taglib, Nepomuk, Soprano 
(ostensibly non-KDE supporting libraries) -- into /opt/kde-4.0 or /opt/kde4.

This would give us four big chunks to deal with, but the dependencies between 
the chunks are fairly straightforward, and you can build in the order I've 
listed things.

[ade]