Wesnoth 1.0 has arrived and so has klik://wesnoth-latest

Yesterday in IRC (#kde-devel) this happened:

  Oct 03 17:13:28 <isaac>     http://www.wesnoth.org/start/1.0/
  Oct 03 17:13:32 <isaac>     we have just got wesnoth 1.0 out 
  Oct 03 17:13:59 <Narishma>  is there a klik package ?
  Oct 03 17:14:06 <misty>     what is wesnoth?
  Oct 03 17:14:18 <Narishma>  misty: a strategy game

OK -- what Misty asked could have been my own question too. Now I know it -- 'cause I even run the game in the meanwhile. The reason was: the above chatter had a continuation. And looking at the backlog, you'll see just how easy and fast it is to build klik bundles from .deb packages that are compiled for Sarge:

  Oct 03 17:44:45 <pipitas_2> isaac: are there .debs of Wesnoth already?
  Oct 03 17:45:21 <pipitas_2> isaac: if so, it will be very trivial to write a 
                              recipe and make a klik://wesnoth package availaible
  Oct 03 17:45:39 <isaac>     they will reach unstable in a few hours
  Oct 03 17:47:13 <pipitas_2> isaac: we prefer packages build for Sarge  --  because 
                              these run practically everywhere
  Oct 03 17:48:21 <isaac>     pipitas_2: I see, I'll backport the packages when I 
                              got some time
  Oct 03 17:49:29 <pipitas_2> isaac: without backport, no klik://wesnoth  --  with 
                              backport, klik://wesnoth 10 minutes later
  Oct 03 17:53:59 <isaac>     pipitas_2: backport for sarge is being built
  Oct 03 18:23:20 <pipitas_2> isaac: great! tell me once it is ready 
  Oct 03 18:23:51 <isaac>     pipitas_2: I'm uploading it to http://debian.wesnoth.org/sarge/
  Oct 03 18:24:04 <pipitas_2> isaac: Oki-dok!
  Oct 03 20:13:11 <isaac>     pipitas_2: wesnoth backport for sarge is ready
  Oct 03 21:01:29 <pipitas_2> isaac: your wish was our command!  So you can now try 
                              "klik://wesnoth-latest" and play your game

Contrary to what the log seems to suggest, it was not me who created the recipe, but probono. And contrary to what the log says, the klik fake URL is for now klik://wesnoth-latest.

Once you have the klik client installed (hey, on KDE it is as easy as hitting [alt]+[f2], typing  "wget klik.atekon.de/client/install -O -|sh"  and following the instructions, just click on klik://wesnoth-latest to enjoy the brandnew version 1.0 of "The Battle for Wesnoth". Don't forget to let us know how it went. Especially if you are a Slackware or Gentoo or Mandriva or Redhat/Fedora user: give us feedback if it works for you. You can also find us in IRC, channel #klik on Freenode.net.

klik, as should be well known by now, was designed to follow the "1 application == 1 file" paradigm. klik creates compressed images of a file system (similar to ISO images that are burned onto a CD) with the extension .cmg. This klik .cmg file system contains all dependencies of libs that are not expected to be present on the target system.

klik prefers to use as its input to the bundle creation process Debian packages built for Sarge. These usually work for other distros (like SUSE-9.3 and SUSE-10.0 too, with some minor modifications required which klik knows about and klik applies).

klik clients build their own bundles themselves (completely transparent to the user who has only to click on a link like klik://datakiosk-demo). The klik server then just sends a "bundle building recipe" in ASCII text format to the klik clients, and the klik clients do all the hard work (download the .deb files from the URLs named in the recipe, unpack them and transform the many input files into the single .cmg file, complete with a wrapper script that is capable of running the result) themselves.

Because of this distributed nature of downloading the input from different repositories, and letting the bundle creation work be done on the client side, while providing the recipes from a central server, klik scales extremely well.

The first of the above screenshots (click to enlarge) shows the .deb packages and their sources used by the klik://wesnoth-latest link to build a 42 MByte sized SUSE-9.3 wesnoth-latest.cmg. The other shot shows the intro screen of the game (heh, I had to run it over an NX link because I didnt know how to take a screenshot from a fullscreen game session...).

I'm pretty sure that this klik-bundle (as most others too) due to its compresssion is considerably smaller (i.e. taking less space on the harddisk) than a standard system installation set of RPMs or .debs on the respective systems. So much for the objection "klik wastes my harddisk space because it includes some libraries in each individual .cmg".