KDE/kdelibs

[Andreas Pakulat]

On 26.11.09 22:33:44, Ian Wadham wrote:
> On Thursday 26 November 2009 8:05:07 pm Tom Albers wrote:
> > I've seen once a document, I think from Allen Winter, which outlined how we
> >  could handle new dependencies. Unfortunately I can not find it anymore,
> >  but I thought it was a good proposal. I suggest we - The Collective - find
> >  that document and accept it as a guideline for these things.... (just mho).
> > 
> Thanks, Tom, that would be really nice!
> 
> It's not just new dependencies but changes in dependencies and even
> some existing long-standing dependencies that impede one's work when
> one has an app which is distant from the core of KDE and the desktop.
> 
> As an example of a long-standing dependency, everyone who wants to develop
> and test with the latest kdelibs has to build kdepimlibs.  Why?

kdelibs cannot depend on kdepimlibs, the opposite is true obviously.

> "Boost" has these weird build instructions and I kept getting errors from
> the build, but eventually I found I had built enough of it to satisfy KDE
> dependencies.  Well and good, but not very confidence-building.  It
> felt a bit like taking off in a light plane when you know there is a loose
> bolt in the engine compartment somewhere.

Why are you compiling boost in the first place? Last I checked kdepimlibs
also works with "old" boost versions (1.37 was the oldest I tried
recently), so just take packages from your distro for that.
 
> Then again, I would like to have a hot dinner for every time somebody
> on the KDE Games list writes about some cool new feature in his game,
> so I go and try to update and compile it.  However one of the other games
> is now referencing a method that has just been added to kdelibs or Qt.
> Then when I build kdelibs, I find something has changed in Strigi or
> Akonadi or whatever ... and on and on, as Kurt Vonnegut used to say.

Thats what happens if you run trunk. If you don't want that, don't use
trunk. Sorry, but either you want "the latest greatest breakage" and hence
have to care yourself for changed dependencies and following the
development of the dependencies you want to build from trunk. Or you take
the stable release and can't see up-to-date features until the next
release.

The only way to change that, is talk to your module coordinator and
establish a rule in your module that it must be compilable and work with
the current stable release of kdelibs&co. Of course that also means having
to wait another 6 months before being able to use the newest features from
kdelibs.

Andreas

-- 
You plan things that you do not even attempt because of your extreme caution.