Klik is a system which creates self-contained packages of programmes installable over the web with a single click. In the article below Kurt Pfeifle discusses the potential uses of this technology for helping the non-coding contributors to KDE. He also looks at how the system works and the obvious security issues involved.
- Can you imagine you just copy one single file onto your system, wherever you possess "rw" privileges (no need for being root) and this file represents a complex, runnable application?
- Can you imagine that with a simple click on a website you could "copy-install" and run such an application?
- Can you imagine that this simple "installation" did not affect in any way the stability of your base system?
- Can you imagine that this file could even run from a USB pen drive? And you just stick it to a different computer to run the application there?
- Can you imagine that you could run the latest official Krita release side by side with Boudewijn's code from last night, without the two versions interfering with each other?
- Can you imagine you revert to your old system again by just deleting one file?
And why would this be relevant or useful?
- It would provide a way to KDE developers for making binary packages of bleeding-edge code directly available to be run by usability experts for early feedback...
- It would let KDE developers give out their bleeding-edge packages to beta-testers well before Release Day...
- It would let translators see (in their actual, lively GUI context) the strings they are working on...
- It would enable art designers to actually *run* a program they are contributing icons and other artwork for...
- It would give a full preview of what will go out to our users at Release Day, to all the different groups of our non-technical KDE contributors (who are not typically compiling KDE every night from the latest checked-out sources)...
- It could happen at any time, completely independent of releases, practically 5 minutes after the code was written and compiled, and long before there are official packages created by everyone's favorite distro...
One can dream, no?
At aKademy I discussed this question with various people. By now everyone in the KDE community is aware of one of my proposed solutions (or that's what I like to think): use a NX or FreeNX driven KDE Application Server, and provide remote access to the programs in question.
However you are wrong if you imagine that my only occupation is NX. I have another, complementing proposal about how to tackle this same problem. One that is an especially nice fit in cases where testers and users do not have network connections.
One that works for Live CD distributions (Knoppix, Kanotix) as well as for Debian, Linspire, Ubuntu, Kubuntu and openSUSE/SUSE Linux 10.0. (No, it's really got nothing to do with NX. Nor with FreeNX. Other than the fact that Fabian, the main developer of FreeNX, has also been a contributor to this klik thingie...)
Take note! It's not a dream. It is reality. It is reality for Linux. It is reality for KDE. It is called klik.
It works on most Debian systems, and on Knoppix (torrent) and Kanotix (torrent) Live CDs.openSUSE/SUSE-10.0 is has recently been added to the list too. Here's how you can test it:
- Install the klik client: press [Alt]+[F2] and paste: wget klik.atekon.de/client/install -O - | sh (this step is not required on Kanotix -- it has the klik client already installed).
- Follow the instructions that pop up on your screen.
- Start Konqueror (it may have opened automatically), and click on one of the links offered in the online klik store.
You could also just type klik://xvier into the Konqueror address field. I actually do recommend to you to start with xvier: it is a simple game that fits into a less than 400 kByte download, so you can have a quick success with klik and see what potential it has...
Neat, isn't it?
klik has been developed by Simon Peter (a.k.a. "probono" in IRC), with the support of Niall Walsh ("bfree"), Jörg Schirottke ("Kano") and FreeNX's Fabian Franz ("fabianx"). You can meet them in the IRC channel #klik on Freenode.
If you are bit security concerned, you may want to know what klik does to your system. Here's the pitch:
- Its .cmg files are self-contained AppDirs (applications directories), compressed into a cramfs or zisofs file system.
- To run the contained app, klik mounts the bundle file underneath /tmp/app/1/ and runs it from there; if mounted, the bundle looks like it is a subdirectory expanded into the real directory structure of the host.
It's very much similar to how applications on Mac OS X works....
If you are even more cautious, or paranoid, you surely want to investigate more closely and see how klik operates on your system. Follow these steps to find out more details:
- wget klik.atekon.de/client/install (this downloads the install file without executing it).
- less install (this lets you look at the installer code: fear not -- it's pure shell).
- less $HOME/.klik (this lets you look at the "commandline client+klik protocol handler" code, of course only after running the klik client install).
- less $HOME/.zAppRun (this lets you look at the commandline starter for klik-ified AppDir bundles, also executed if you just click on one of the .cmg files).
- less {$KDEHOME,$HOME/.kde}/share/services/klik.protocol (the secret behind the klik://my_cool_app links, part 1).
- less {$KDEHOME,$HOME/.kde}/share/applnk/klik/klik.desktop (the secret behind the klik://my_cool_app links, part 2).
- less {$KDEHOME,$HOME/.kde}/share/applnk/klik/.directory (why there is now a klik icon and a klik entry in the K Menu).
- less {$KDEHOME,$HOME/.kde}/share/mimelnk/all/cmg.desktop (why klik is now responsible for handling clicks on files that happen to have a .cmg suffix, part 1).
- less {$KDEHOME,$HOME/.kde}/share/applnk/.hidden/AppRun.desktop (why klik is now responsible for handling clicks on files that happen to have a .cmg suffix, part 1).
- less /etc/fstab (why klik can now find mountpoints in the file system to mount the .cmg AppDirs on execution).
- ls -lR /tmp/app/{7,6,5,4,3,2,1} (list the directories underneath the mountpoints while one of the .cmg AppDirs is executed).
klik's smartness is all contained in a few shell scripts and typical KDE config files, as you can easily see...
For most of the 4000+ packages available from the klik warehouse, the "download" consists of a "recipe". The recipe tells the klik client where to fetch the binaries from (in most cases .deb packages from the official Debian repositories), how to unpack them, and how to re-package and compress them into the final .cmg image. So the klik client does most of the work and builds its own .cmg file in most cases.
If you want to look at one such recipe, here is the klik recipe for Scribus.
There are other packages which have been built on the server (and hand-tuned and tested) so that they work with non-Debian distros too ("serverside apt"). In this case the klik://some-app link will fetch the ready-made .cmg from the URL the klik server names in his recipe. The special "klik apps for SUSE 10.0" repository is filling up by the day. Warning: currently this will only work for openSUSE/SUSE Linux 10.0, not for other Distros!
You may be interested in trying the following links, if you have more bandwidth (note: they'll not work for you unless you install the klik client). They work on openSUSE/SUSE-Linux 10 RC1 very well, and also support Knoppix, Kanotix, Debian, Linspire and Kubuntu (other distros are untested):
- klik://apollon (downloads 2.2 MByte)
- klik://firefox (downloads 10.0 MByte)
- klik://skype (downloads 10.2 MByte)
- klik://frozen-bubble (downloads 14.0 MByte)
- klik://ooo2 (downloads 114 MByte) - Martijn can use this to read .odt files easily!
I found the ooo2 bundle (representing the OpenOffice.org 2 beta release, build 125 by Novell) on par (or even better) in speed and responsiveness as the "real" RPM package that I installed from the RC1 iso images for SUSE Linux 10.0.
If you are a type of person who likes to startup apps from the commandline, use the klik commandline client like this:
- $HOME/.klik klik://ktorrent (installs the cool KTorrent BitTorrent client).
This will prepare the .cmg AppDir bundle and run it once ready. Once .cmg file is on your system, the commandline to run it (without a repeated download) is this:
- $HOME/.zAppRun /path/to/app123.cmg (runs the application named app123).
I have already browsed the web with Alpha version 1.6a1 of Firefox to see if the hype around it is justified. To do so, I tried the old-fashioned manual installation of the klik-ified Firefox:
- mkdir $HOME/klik-downloads
- cd $HOME/klik-downloads
- wget http://opensuse.linux.co.nz/klik/10.0/firefox_1.6a1.cmg
- $HOME/.zAppRun firefox_1.6a1.cmg
I am pretty sure, that at least some of our beloved KDE-PIM hackers will like this new way to take a quick look at their valued competition, without needing to install it:
- klik://thunderbird -- the Beta 1 of upcoming Thunderbird 1.5, the Mozilla mail client (klik bundle, direct link)
- klik://sunbird -- Development version of Mozilla calendar application (klik bundle, direct link )
Now, developers, what do you think of a tool that lets you easily create binary snapshots of your own development versions in the form of those nifty "Don't Install, Just Copy!"- .cmg files? -- Which of you will be the first five to step forward and receive the service of getting their SVN weekly builds packaged as .cmg AppDir bundles, for the next 3 months?
I know Boudewijn has been struggling in the past to provide Krita snapshots to a dozen beta testers and non-technical contributors, and to help them compile the code, or to support them installing binaries he had built.
I also know that I definitely would love to get quick access to kpdf, KWord, amaroK, Quanta and Kommander snapshots which I can run on my stable system with the reassuring feeling that the most that can go wrong is that the test app doesnt run at all, and all I had to do is just delete it again, to have my system reverted to its original state.
What about our friends from OpenUsability.org? Would they appreciate such a service too? Have they ever looked at the added value klik:// can offer to our common development workflow?
Comments
Wow. It looks like a really neat idea. It could use a little polishing, for example having multiple sites to look for the download for an app. That way if one is down there wont be any problems with downloading as it will just use another one. Great job.
Take that, linspire....
Mark
Perhaps instead of multiple sites, now is the time to move to an easy torrent set-up for doing this kind of klik installer. have a script (or a set of scripts) that builds the klik, the torrent, and an rss. Likewise, it should also handle the update issue. Perhaps, when you load the klik on your system, an rss url is included that can be loaded into a local update app to track the what and where. That way, if an update does occur your system finds out about it.
Do you _really_ want to run software from random torrent peers?
This shouldn't matter, as long as the source of the .torrent file is trustworthy. In theory at least. But IIRC bittorrent uses md4 (not md5 or sha1) checksums, so maybe it's really not as tamper-proof as it could be.
why are you addressing Linspire there?
Fab
yeah, there is no reason why it won't work in linspire... on the other hand, linspire has one-click, too - so i guess that is what he wanted to say :D
Booaaaaaaaaah!
This is brilliant!
Reading the article first, I thought it was an April Fool's joke gone late. But then I tried it with the klik://ooo2 link -- and boy!, was I suprised. (Really nice splash screen made by the Novell artists, BTW.) This thingie runs wonderfully. I'm still wondering how they did it (not really understanding Kurt's explanations about what makes klik tick...).
How would this work with libs? are they compiled into the cmg-file so there wont be any dependencies?
Yes, the cmg will include required libraries. What is required in the cmg is determined by assuming all target systems will have a certain base set of packages. Anything required beyond those base packages (or which requires a newer version then can safely be assumed to exist) is included within the cmg making it quite self contained. The klik server is aware of the full installed package set for many of it's supported distributions and can provide quite small (but less portable) packages for them using "serverside-apt". For unknown distributions the server defaults to assuming that the target system will have a "lowest common denominator" of packages provided by the supported distributions (including debian sarge), e.g. the cmg will only assume the target system has the packages installed which are in all supported distros, and only at the lowest version in any supported distro.
To complement it, you can find more information on klik's architecture here:
http://klik.atekon.de/docs/
1 yr. ago I taught my 71 aged Grandma how to use Kanotix + email/KMail + webbrowsing/Konqueror. She really enjoyed it.
3 months ago she phoned my and complained: Why hadn't I told her about that easy one-click installation method of new software?!
I didnt get what she wanted to explain to me. She got angry and hang up, when I told her this was impossible...
Last month we went to visit her. She showed me how to do it. You can imagine that my jaws dropped 10+ inches. I must have displayed the most stupid face I ever made in my life.
So, yes -- klik rulez! And it was introduced to my not by this nice article, but by my beloved Grandma...
excellent points
In fact, the aoutopackage folks, for this very reason of package consistency and maintainability, only recommend autopackage for certain, almost self contained packages (think firefox, open-office, games)
cheers!
sorry, I meant to post this in liquidat's thread below
Does your Grandma read the Dot to?
guess so :D
Would it be difficult to get this working on slackware ?
This could really be interesting, instant beta testing. No need to explain people how to get the svn version of KTorrent, just klik and try it.
Btw, You have the knoppix and kanotix torrents mixed up.
### "difficult to get this working on slackware ?"
----
No. Not at all.
Are you volunteering?
### "knoppix and kanotix torrents mixed up."
---
Rats! (I'll try to see if a dot editor can fix that. Thanks for the hint.)
"knoppix and kanotix torrents mixed up" are fixed now.
To busy with KTorrent and I start to work next week, so not enough time.
Have you already tried klik://ktorrent ? ;-)
on my slackware it works pretty well:
it must be payd attention only on two little things:
-check that you have a kernel with loopback filesystem and cramfs compiled in
-it helps but not necessary copying /sbin/pidof to /bin/pidof
Sounds nice, but after reading the faq, http://klik.atekon.de/docs/?page=FAQ, there are still some questions open:
- Is there an update system integrated? If I can install >20 packages I am not able to look after updates, especially if I am a normal user!
- What is, if the installed version replaces an old, system wide installation? Which version will be used?
- Where is the difference to the autopackage system? What is better, was is worse?
...
liquidat
### "Is there an update system integrated?"
----
No. You'll have to look yourself for updates.
However, some of the latest packages include version numbers in their names. So it would be easy to "install" (it is just copy, really) the "krita-1.4.88.cmg" side by side with "krita-1.4.0.cmg" and "krita-2005.17.09.cmg" and even run all 3 in parallel.
### "If I can install >20 packages I am not able to look after updates, especially if I am a normal user!"
----
May be true.
However, my own idea about klik is to use it primarily as a very efficient tool to help experienced users to testdrive development versions of KDE packages without them needing to compile themselvs, and without the distro packages needing to provide weekly snapshot RPMs and .debs (which they don't do, anyways).
Let's see how the idea is accepted. If it gets enough support, someone may even think of hacking the Makefiles so that there is a "make cmg" target available for everyone who compiles KDE apps on his own host.
### " What is, if the installed version replaces an old, system wide installation?"
----
A klik .cmg file never replaces an installed old, system wide software. It is there as an alternative.
You can run the system wide installed app side by side with the klik version. (The only conflict you may need to watch out for is that both may write into the same $HOME/.yourapp and $KDEHOME/somewhere files and directories with conflicting content...
### "Which version will be used?"
----
klik may have put its apps into your K menu. But even there it does not replace the installed app's entry. To the system, it looks like a separate app.
Great article and great tool, thx. I'm kliking ooo2 ;-).
But I think the problem with applications writing to the same config files could become a real problem for some persons.
Anyway, great tool, but how do I uninstall it?
### "great tool, but how do I uninstall it?"
----
Why should you ever want to uninstall it in the first place? ;-P
Seriously: to get rid of everything klik installed (including possible K menu entries), running these commands should accomplish it:
rm $HOME/{.klik,.zAppRun} \
$HOME/Desktop/*.cmg \
{$KDEHOME,$HOME/.kde}/share/services/klik.protocol \
{$KDEHOME,$HOME/.kde}/share/applnk/klik/{klik.desktop,.directory} \
{$KDEHOME,$HOME/.kde}/share/mimelnk/all/cmg.desktop \
{$KDEHOME,$HOME/.kde}/share/applnk/.hidden/AppRun.desktop \
rm -rf /tmp/{app,klik}
Last, edit /etc/fstab to remove the /tmp/app/{1,2,3,4,5,6,7} mountpoints.
Cheers,
Kurt
> ### "Is there an update system integrated?"
> ----
>
> No. You'll have to look yourself for updates.
Would it be possible to integrate this system with the GetHotNewStuff system? If I remember correctly, that is set up to allow for a central server that shows versions of files and everything so that the end user can see, in a list, what is already installed on their system, what is installed on their system and could be updated, and what is not installed on their system at all.
Of course, I haven't particularly used GHNS of Klik, so I wouldn't have any idea what I'm talking about, but I much prefer the idea of Klik if it makes not only installing, but also updating as easy as clicking a button. Also, I'm always a fan of reusing technologies, so...
I think it's a good idea, and i've used both :D
yeah, i think it should work. maybe this is the solution to the problem of c++ applets/plasmoids... and to the problem of installing kde applications. I think, and some others do so to, kde itself should be smaller, and the additional applications should be installable easilly. if possible with an KDE interface.
The update system is to klik/install the latest version of any application you want.
You run the program from the cmg normally by clicking on it, typing the command name at the command line will use the normal system installed version. Your system is uneffected, only the application you have installed, when run from the cmg, will see any alterations.
Autopackage is completely different imho. Autopackage is still a normal system installation tool, klik is not. Klik is a complimentary technology to normal system installation tools/processes, which uses them to take care of the things they do best (dependencies) but provides an alternative way to use the information and software they hold.
Correct me if I'm wrong, but klik seems to be more like Apple's Fat Binaries. A great solution for a specific problem (as in distributing testing / nightly versions of software in this case). It takes care of dependencies by putting all libs, but an agreed upon base set, in the package and you just stick it wherever you want and run it.
The aims of Autopackage are different/broader as it seeks to be a solution for distributing end user stable versions, without duplication of Libs and ultimately integrating it with the native distro package system be that tar.gz, deb, rpm or whatever else. It also a non-root user install locally and then informs the root user so he/she can install it globally if he/she thinks its pertinent. Actually those are just some highlights that I find important for me :) The Autopackage aproach is way more complicated, both to implement and to get working right, as there are, due to it's complexity, more points of failure. BUT... it solves a greater set of software distribution problems than klik.
My evaluation: Klik seems great for the job it was created (running testing/nightly builds on a tester/developer machine) THANKS GUYS. To install software on a non-testing machine, where things need to be installed globally, not duplicate lots of libs, allow easy updates & integrate well with the distro, there's Autopackage.
I have followed the Autopackage mailing list for many monts now and it is really exciting to see how they are solving the problems that crop up. Before I started reading the mailing list I had a vague idea that Linux Distros worked very differently and where using different incompatible versions of basic libs, but now that I see the guys at Autopackage solving so many things to be able to achieve their goal, (making relocatable binaries, dealing with different File structures and config systems, packaging systems etc) I see their efforts in a totally different light. It's a difficult task, but they have done very well so far.
Congrats on y'alls achievements with klik. It will make my complusive nightly testing and cutting edge feature admiring much easier ;)
Cheers,
Andreas
Montevideo, Uruguay
Yes, it is more like an "Apple Fat Binary" then an autopackage.
I was unanaware (or had forgotten) that autopackage was usable by normal users to install software without administrative priveleges. I guess that puts klik and autopackage into "slightly" more competition which is never a bad thing :-) That being said, they address different needs, as you have pointed out, and have a fundamental difference, klik bundles dependencies and allows the "installation" of an application to have zero impact on your system (ok it might add a menu entry and maybe an icon to your system).
As I now understand it in user mode with autopackage the installation of one newer package could pull in updates which adversely imapct other software you have running. The flip-side is that autopackage can pull in underlying library updates which can see improvements in other applications. This is not trying to say klik is better then autopackage, just that they address different issues so comparisons can only really be made carefully. One updates a software system, the other simply makes programs available to run on a system. Horses for courses.
As I understand it if autopackage was successfully generally adopted by packagers , klik would have few if any problems using autopackages as the sources for it's cmg files.
I think you have explained it well, Autopackage is still in the process of solving certain issues (although it's very usefull already). And I agree with you on you last statement, I don't have a clue if the developers have thought about that, They might. I think it would be cool if it was possible for developers to easily create both types of packages simultaneously. That would be great. I think having both types of packages created and available for a software would be very profitable.
Cheers,
Andreas
"ok it might add a menu entry and maybe an icon to your system"
While I do not mind the addition of an icon or configuration files to my system, I find the menu entry a bit intrusive. While one can safely ignore the addition of an icon or configuration file, menu items are a different story. They are more difficult to remove (for end-users), particularly since klik doesn't have "uninstall" options. If the purpose is to avoid a "true" installation, then it shouldn't have a visible effect (when it isn't running)... Any behavior that is somewhat permanant is a "bug", IMHO.
Hence, I have a suggestion. Would it be possible to either:
A) Create a "subsystem" within KDE that automatically removes any "cruft" that this would add to the system (over time)? Eg. When I delete the klick package, it could automatically remove any .desktop items that point to it/etc.
B) Instead of adding menu entries, could it be integrated via plasmoids? (KDE 4) It would be great to have a plasmoid that stores your last N klick downloads. For KDE 3.5 this could be implemented by either putting icons on the dekstop, or creating a kicker applet).
I don't really know if either of the above solutions are implementable. However, if one of them (or something similar) would be implemented, this system would definitely be a nice complement to autopackage.
I agree with almost all you have said, but I wouldn't limit the scope of klik as much as you did. I think it's also interesting for end-users.
Just a few use-cases, where I think that klik would be useful:
a) You want to try-out a new version of an application without removing the current installation.
b) You want to try-out a new application but you want to make sure that you can remove it cleanly without disturbing the rest of the system.
c) You are on a multi-user machine and really want to use this one application that the sysadmin doesn't care about. :)
Besides the amount of duplicate libraries really depends on the definition of the base libraries. When you see Qt and kdelibs as part of the base system than the duplication is IMHO negligible.
How about that application where nobody has bothered yet to make a package for?
Or just because it's so damn easy to click on a link and start using the app?
Of course! My list wasn't meant to be exhaustive. :)
You're totaly right... my comment was not so much about what klik can do... but rather about how Autopackage complements Klik or vise-versa.
Scenario 1. I am the Admin
I can even think of a situation where I would use klik to test, check out the feature set or just generally check out a new tool I am thinking of deploying, and then (assuming both klik and autopackages are available... would be nice) once I want to deploy it for the rest of the users, I'd just get an autopackage and install globally, which would give me a few other advantages (as mentioned in earlier post). Or get the rpm, deb or whatever the native package format is.
Scenrio 2. I am just Joe User (or Andi user in my case :)
I want to run a tool my Admin does not have available, and probably won't provide... I get the Klik package and I am done, or I can get the Autopacke which also works, BUT: More than likely though, with me being one of those guys who likes to carry everything with Him (yes, I got a notebook... but the battery is dead, the powersupply is dying, I live in South America and got married recently - i.e. I can't afford a new one), I'd just put the Klik package on my USB stick and carry the tool with me... ;) Can't do that with Autopackage...
So, really In my earlier post I was just trying to clarify some more the usage of Autopackage (which is what I know more about) and not as much to explore the multiple uses of Klik.
I think there is some overlap in possible usage cases, but I still think that they are sufficiently different that a developer might want to publish binaries of all builds (nightly, alpha, beta, rc and final) with Klik and then maybe only publish final builds or maybe beta, rc and finals with Autopackage. I believe it's definitely not an either - or type scenario, but rather a matter of using the right package type for the right job and/or target audience.
Cheers.
Can't do that with Autopackage...
You can create sealed installers with Autopackage, as well as stick the Autopackage support code on a USB drive, and then you have a stand-alone Autopackage. :)
Or maybe I completely missed what you meant. :)
--
Taj
Taj,
thanks for correcting me... that's exactly what I meant and I was wrong. That's why I sent a message to the Autopackage mailing list asking everyone to come over and join in the discussion, so the developers themselves would comment on Autopackage and correct any missrepresentation on my part.
Great to see you guys are joining in! You are the ones qualified to talk about Autopackage!! I just try and spread the word, though my understanding might not be complete.
Thanks!!
Andreas
Taj,
thanks for correcting me... that's exactly what I meant and I was wrong. That's why I sent a message to the Autopackage mailing list asking everyone to come over and join in the discussion, so the developers themselves would comment on Autopackage and correct any missrepresentation on my part.
Great to see you guys are joining in! You are the ones qualified to talk about Autopackage!! I just try and spread the word, though my understanding might not be complete.
Thanks!!
Andreas
Taj,
thanks for correcting me... that's exactly what I meant and I was wrong. That's why I sent a message to the Autopackage mailing list asking everyone to come over and join in the discussion, so the developers themselves would comment on Autopackage and correct any missrepresentation on my part.
Great to see you guys are joining in! You are the ones qualified to talk about Autopackage!! I just try and spread the word, though my understanding might not be complete.
Thanks!!
Andreas
Autopackage can do c). As for a and b, parallel-installs are slated for 1.1, but they're not implemented yet.
Patches welcome!
--
Taj
It would be nice to see the packaging tool create a torrent file, and an RSS file. Then when adding a klik, it can be registered in a DB with the RSS url. When needed, it simply torrents it down. In fact, the tool could be set-up to do autodownload (nice for nightly downloads) with the use of torrents (but the file could be palced in a different directory until the user has had time to approve the install). That way, most of the downloads occur in the first night (lots of systems to work with).
Debian not on supported distributions lists? Sound kind of strange since all those distributions debian derivatives? Am I missing something here or what?
### "(....) works for Live CD distributions (Knoppix, Kanotix) as well as for Debian, Linspire, Ubuntu, Kubuntu and openSUSE/SUSE Linux 10.0."
----
This looks to me like I listed Debian amongst the supported distributions... ;-P
Ok. Sorry missed that one while looking at this page (which lists supported distributions):
http://klik.atekon.de/docs/?page=How%20to%20use
But thanks for sorting the misunderstanding :)
There is support, but I like to maintain my debian system
by apt-get'ing (now aptitude'ing) packages when possible.
This way they're tracked via dpkg --get-selections, and I
can minimize items I need to track should I need to perform
a bare-metal reinstall.
I heard a 'slh' on #kanotix (irc.freenode.net) has .debs, but
it would be nice to pick them up from klik or backports.org
(or the like).
I can't believe my eyes!
Just out of curiousity, I installed the klik client (very nice background info in Kurt's article, I really appriciated to read it and follow it through), and visited the mentioned openSUSE repository in .NZ to see what it had to offer.
Enlightenment poked my interest.
I run klik://enlightenment, and the popping up dialog informed me that it had discovered a SUSE 10.0 system, and it wanted to download 18 MByte of software. I confirmed, and 3 minutes later I had a georgious E17 desktop starting inside an Xnest window. All fully automatically! No installation, no configuration! I can't believe it!
### "(...) a georgious E17 desktop starting inside an Xnest window."
----
;-)
Yes, I was myself pretty impressed with the enlightenment package probono created a few days ago within 2-3 hours after it was requested in the #klik IRC channel.
It used indeed Xnest at first.
I suggested to use "nxagent" instead of Xnest (because it can be resized, and doesnt have a fixed window size, like Xnest), but unfortunately the current version has nxagent from 1.4.0 included (which does *not* support resize).
So I hacked my local .cmg myself. It was pretty easy to de-compress the .cmg into a directory tree, take out the old version of nxagent (including the old nx libs) and put in the 1.5.0 version (including the nx libs).
So my local enlightenment.cmg now starts up in a window that I can resize at will. And coolest thing: it even obeys the [CTRL]+[ALT]+[F] shortcut to toggle the window into fullscreen mode and back!
Thats freaking awesome... and maybe a little creepy!
yeah, this is frightening... the MS ppl won't like this. now they took most of plasma's ideas into their 'gadgets' but this will be hard for them to do :D
they still don't have a centralized way of packagemanagement (and especially upgrading)...