On Sunday 27 November 2005 16:58, Bryce Harrington wrote: > On Sun, Nov 27, 2005 at 01:09:54PM +0100, Martin Konold wrote: > > Am Freitag, 25. November 2005 08:29 schrieb Bryce Harrington:
> > > another have some trouble getting a given rpm installed on their > > > system, due to dependency, glibc, or other compatibility problems. ??Our > > > first response is always, "Have you tried the autopackage?" ??Invariably > > > within 15 minutes we have a happy user. > > > > Did you investigate into KliK? > > > > http://klik.atekon.de/ > > Yup, we looked at that too; it's similar in many ways to autopackage. > There's a klik package for inkscape, but we've focused on the > autopackage version. I haven't looked at klik enough to know the pros / > cons vs. autopackage, so it'd be interesting to hear a comparison from > someone who's worked with both. OK, here is my shot at it. A bit belatedly, though. I had intended to do a writeup immediatley, but real life has been a bit nasty to me, not allowing me enough time for my a favourite hobbies such as dealing with Free Software topics.... :-) This mail will provide you an "Executive Summary" about klik. One of my next mails will outline some more details about the "Technical Background" of klik. ======================================================================== autopackage and klik do different things (with similar goals). They both can co-exist nicely, and benefit from each other. Let me first outline what features klik has. So if you do not have too much time, the summary in this mail should be enough to provide you with an initial/overview pitch. Read the next mails only if you need/want to know more. klik: "1 application == 1 file" ------------------------------- * klik gives the user the option to run nearly any application by copying exactly 1 file (to any place) he wants and "run" that file; User needs no root privileges. No "installation", no hassle... * klik does not touch the base system libraries and does not change any of the dependencies present there. No dependencies, no hassle... * klik does not touch the native packaging system (.rpm, .deb, .tgz, whatever). No failed library installation caused by klik which may render a complete system unusable. * klik can provide a "drag and drop" installation to the user who only ever has to deal with 1 file (and likewise, an easy "drag to the wastebin" package removal too). * klik allows different versions of the same application to be used on one and the same system, without needing to remove another version first. * if a klik package doesnt work, only that one package itself is malfunctioning. It will not have overwritten or removed another (working) version (or even the system provided version!) and leaving the user a non-working system from a failed upgrade. The klik slides (4 pages only) provided for the "Portland Meeting" are here as PDF: http://groups.osdl.org/apps/group_public/download.php/1719/klik.pdf (I'll attach an ASCII version of them to the end of the next mail). klik vs. autopackage (as I understand it) ----------------------------------------- * autopackage aims for portable and easy-to-install software, -- klik aims for portable and easy-to-install software too. * autopackage uses source code as input and compiles *.package binaries, -- klik uses readily packaged binaries as input (*.rpms, *.debs., *.tgzs, *.tar.gzs, *.bz2s ...and even *.packages!) and converts them into a different package * autopackage is for developers (to let them build easy-to-use installers for their software), -- klik is for end users (and automatically converts existing binary packages into easy-to-use files that run *without* any installer). * autopackage provides a long term solution, -- klik works here and now. * autopackage often requires changes to the source code before a *.package can be successfully built, -- klik uses binaries that are already available now. * autopackage asks packagers/developers to learn new skills in order to create portable packages, -- klik lets packagers keep packaging whatever they are used to (.rpm, .deb., .tgz) * autopackage-d binaries are available for only very few programs (about 200?), -- klik bundles are available for more than 4000 different applications. * autopackage creates very "clean" binaries which (once they are completed) are relocate-able and highly portable across systems, -- klik applies "quick'n'dirty" patches to existing binaries to make them relocate-able and portable. * autopackage mercilessly and without a warning overwrote my existing, current and fully featured stellarium-0.7.2 RPM installation with its out-moded and crippled 0.6.2 *.package version (yes, I should have read the autopackage instructions first instead of running the commandline installer straight away) :-), -- klik gracefully let my system-installed 0.7.2 stellarium stay where it was without hurting it with the slightest scratch so I could run both versions in turn to compare them and their respective features, without removing the other. * autopackage in general "messes" with the system installations, replaces binaries and libraries, and changes the file system hierarchy, -- klik leaves system installations (binaries, libs) alone, doesnt touch the file system hierarchy and doesn't interfere with the native package manager. * what klik does and produces is not very useful to the autopackage development effort, -- what autopackage does and produces is extremely beneficial for klik. * klik developers love the autopackage effort and wish it all the success it deserves -- after all, if autopackages guidelines were followed everywhere a software is built, and if autopackage-provided tools were used universally, all klik packages could be made by default from *.package binaries, and would be so much more reliable and portable across distros! Short klik client installation instructions (20 kByte download -- 20 seconds effort): -------------------------------------------- * run "wget klik.atekon.de/client/install -O - | sh" from an xterm, konsole or another terminal emulator * follow instructions provided to you on screen; if you are no sudoer, you'll be asked the root password once, so that klik can add 7 mount points to /etc/fstab (from then on, users will be able to mount and run klik .cmg bundles without root privileges). * in Konqueror or Firefox address bar type "klik://xvier" (in case of Firefox: needs to be closed first and re-started) (xvier is the klik reference application bundle, a very small-sized "4-in-a-row" game that serves as a reference klik app installation to verify the klik client works as intended). A few suggested applications to test klik with: ----------------------------------------------- (I'll post some more extended descriptions in one of my next mails) NOTE: do not be scared by seeing an RPM downloaded onto your Debian system, or a .deb onto your SUSE; it is all by design, and will not harm your system! The worst that can happen is that the bundle just doesnt work. In that case, simply delete it. proprietary, commercial ISV products: klik://skype klik://opera9 klik://planmaker open source, commercial ISV product: klik://wengophone open source, non-commercial ISV product: klik://firefox ex-proprietary, soon to be open-sourced product: klik://xara-latest open source, alpha-quality, technological preview (fully functional): klik://thunderbird16-tabbed KDE programs: klik://kstars klik://taskjuggler klik://klamav klik://kalzium Qt programs: klik://scribus-latest Gtk programs: klik://stellarium klik://gimp klik://inkscape-latest Tcl/Tk program klik://amsn-latest A few reading suggestions: -------------------------- http://dot.kde.org/1126867980/ # klik introductionary article providing some more background http://klik.atekon.de/wiki/index.php/User's_FAQ # FAQ, providing background, plus help for the most common problems http://klik.atekon.de/architecture/ # very short klik architecture overview http://www.kdedevelopers.org/blog/418 # My blog, with lots of updates to klik developments > > In short klik allow a simple click on a download link and the application > > is > > installed on the host system in a rather secure and confined manner. > > > > You may check out Kurt Pfeifle's excellent introduction to Klik "Don't > > Install, Just Copy with klik" > > > > http://dot.kde.org/1126867980/ > > Bryce I'll provide some more details in the next couple of hours or days (depending on how my time and life in general permit me to write it up). Cheers, Kurt
_______________________________________________ Desktop_architects mailing list Desktop_architects@lists.osdl.org https://lists.osdl.org/mailman/listinfo/desktop_architects