Long time no post so here a small status update.
Two weeks ago I participated the kate developer sprint in Darmstadt. I'm very glad that the kate devs invited me to their sprint and say thanks to Dominik who organized the meeting and Joseph Wenninger and BaSysKom for the dinners.
Although I could not help much within their design decisions I got a lot of insight how kate works and what it should be (apart from an easy text editor). I could also fix two annoying bugs (properly restore cursor and selection after Undo/Redo) which bothered me since the first day I used kate. :)
A new binary snapshot (4.0.70) is available during this day. We could not release .67 - .69 because we had some troubles with qt4.4-rc1 and I switched my build system to cmake 2.6.0-rc. It took more work than expected but it's a good test for the cmake devs to be backward compatible.
We're looking forward to split down our packages from e.g. one big kdeedu package to one package for each app. The problem is that I don't have a nice idea how to solve this with cmake so we get all our dependencies automatically. How do the Linux packagers solve this problem?
Mittwoch, 23. April 2008
Abonnieren
Kommentare zum Post (Atom)
4 Kommentare:
use checkinstall? have it output each package to a common directory.
> How do the Linux packagers solve this problem?
In Fedora, we don't, e.g. we have one big kdeedu package.
In Debian, they divide it using their build system, look up the source package for kdeedu and you will see it :) They provide the metapackage names kdeedu, that depends on all the apps from the kdeedu-package they get from KDE. Their build-system divides it up into semi-independant debian packages that simply depend on kdeedu
Kommentar veröffentlichen