Quote Originally Posted by probono
"Next generation" klik (http://klik.atekon.de) addresses these questions:

Yes, some of the more sophisticated packages with many dependencies can already be kliked (such as koffice).

klik does not aim to handle the dependency database client-wise, instead it uses apt on the server ("serverside-apt").

Please forgive my ignorance of jargon, as I'm not a developer. Just a poor guy who doesn't like Windows much...

Are you saying that you keep all the dependency information on a centralised "klik" server, and the guest client activates some program(s) on that server upon "kliking" that handle the dependencies as a remote request?
So the database of packages in your "klik" server (for want of a better term) is not mirrorred in the client's machine as is done with apt-dpkg/ipkg & rpm-yum/urpmi/YaST but queried by the client to the server every time?

If that is the case, then what about bandwidth problems? won't you have a lot of clients doing it at once? What about people with slow network connections?


Dependency handling can be done very elegantly that way. A bigger concern (and the reason why LyX can't be kliked yet) is that some apps rely on hardcoded paths such as /usr, or even worse, need to have hundreds of configuration subfolders in place (gconf, which is used by evolution).
So you will have to change 'em all manually in the source code. That doesn't seem practically doable by one person or one small team as some of those source codes are *HUGE* and took years to build. That does sound like a bit of a snag there.



Anyways, so how many people are working on this "klik" thingie besides you?
What's the group dynamic like, or is it just one chap? How rapid is the development/updating/bugfixing process? How is the whole process organised?