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 pressent 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). The klik server 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.
Above screenshot 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.
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".
Syndicate Blogs