klik avalanche (2): more news from the klik front

Boudewijn, the Krita maintainer has his first krita-latest.cmg on offer. It seems to be a resounding success to him, with the download number approaching 300 within the first 24 hours already, and some dozen feedback mails. He even found bugs (and fixed them too) which could not have been found without users actually starting to use the current Krita snapshot for real -- by kliking on the krita.cmg file. (Yes, we are also aware of some bugs which are due to the .cmg file -- missing libraries, missing symlinks; these will be fixed with the next krita.cmg). Boudewijn had success reports on Mandriva, SUSE 10, SuSE 9.3, Kanotix, Debian (with kde 3.4, so fairly adventurous debian users) -- but not all could actually import files. Since the package uses a compilation done on a KDE-3.4 system, there seem to be problems on running it on KDE-3.3 systems (So much for our own ABI backward compatibility, no? Uhmmm... or we better blame GCC for this, because it breaks the ABI of code compiled with each new minor version release). We will try and compile one of the next versions on a 3.3 system, and see if that helps (need to find or setup one first). Due to the success, Boudewijn is now a bit concerned, that the 2 Gig downloads caused by his krita.cmg may after all be giving his provider second thoughts. That's why we are looking into providing a klik://krita-latest shortcut via the klik server, that will fetch the copy of the krita bundle from another source than boud's server.

More news items:

  • Various KDE hackers have queried me in IRC or by mail about how to create my-cool-application-the-latest-development-snapshot.cmg files. I'll publish a short HOWTO about that soon.
  • probono is pondering to introduce a system of klik package.... no, klik recipe maintainers, whose job it is to track all the feedbacks that come in (nearly by the minute) on the klik website (well, not right now -- because of the DNS problem mentioned in my last blog entry), and fix the problems that occur. You can imagine that most of the 4.000+ recipes offered by the klik server are not yet tested at all, or even manually tweaked. They are auto-created by scripts. And yet they work on many systems already, very often even extremely well. I've seen [fab] expressing his satisfaction about how well klik://apollon worked for him.
  • We had some great input of ideas in the #klik channel on Freenode about how to include application icons and display them for the .cmg files while still sticking to the paradigm that makes klik such a big success: "1 application == 1 file".
  • I am working on two other klik recipes (for KOffice and KDEedu) which would put multiple applications into one file even, and still make it possible to access them individually. Let's see how far this leads... I'm sure probono has a solution for this already.


Backwards compatibility means that you can run an application, which has been compiled on a KDE 3.3 system, also on a KDE 3.4 system. OTOH, an application which has been compiled on a KDE 3.4 system will usually not run on a KDE 3.3 system because it already uses symbols which have been introduced in KDE 3.4.

So if you want to release a binary of a KDE application which should run on KDE 3.3 and later then you have to compile it on KDE 3.3.

By Ingo Klöcker at Thu, 09/22/2005 - 08:21


thanks for this explanation. I had gotten it wrong, and you have upgraded my mind now, at least on this question. ;-)

Cheers & thanks,

By Kurt Pf. at Fri, 09/23/2005 - 12:32

You can improve the binary compatibility of packages by compiling with apbuild, found at This is a wrapper for gcc/g++ which forces the linker to link against older GLIBC symbols, and remove bugus dependencies. That's how Autopackage manages to produce distribution-independent packages (and they've done a lot of research in that area).

Currently apbuild officially supports gcc/C only. Full C++ support is expected with the 1.2 release of Autopackage.

By vdboor at Thu, 09/22/2005 - 12:48

Hi, vdboor,

thanks for pointing to aptools. We had seen this already, and we are hoping to be able to test its capabilities re. C++ some day soon. Unforch, it only works for C code right now.


By Kurt Pf. at Fri, 09/23/2005 - 12:31