> [EMAIL PROTECTED]
>
> > There seems to be a fairly good amount of Debian Sarge packages
> > available via http://klik.atekon.de/.
>
> You know, I almost didn't bother to visit the web site, since you're
> unwilling to even sign your name to your message, and you didn't say
> anything about what klik is or why we should care. I was bored,
> though.
Peter,
I'm sorry that someone I do not know has (stupidly) decided to
anonymously kick off a klik discussion on this list. He/she may
think he helps klik and/or Debian, but I'm afraid this is not the
way to go about this. I say so as one member of the klik project
team. (I'm not subscribed to the list, and I'll CC you because I
don't know if my mail goes through. Thanks to SLH who came to
#klik on Freenode to inform me about this thread.)
> For those following along at home, it seems klik is some sort of
> gateway to install Debian packages on various non-Debian distributions.
> I imagine it's an ftp frontend to alien.
Not quite right.
Essentially, klik is a web service that delivers "recipes" for klik
<applicationnane>.cmg bundles to the klik clients. The klik clients
execute the recipes (shell script) to download (possibly multiple)
input packages (.debs, .tgzs, .rpms, .bz2s, .packages,...) and convert
them into one single *.cmg file.
The *.cmg is a complete compressed file system (cramfs or zisofs)
similar to an ISO image, cantaining all the direct depencencies of the
<applicationname> to run successfully.
A klik *.cmg image file contains two types of components:
a) all the required binaries, libraries and data files to run the
contained application
b) a wrapper script (call "wrapper") that uses PATH, LD_LIBRARY_PATH
and a few other simple settings to allow running the .cmg file as
a more or less self-contained thingie.
The *.cmg currently needs to be loop-mounted before exectution of the
wrapper. That is done by an external helper script (part of the minimal
klik client installation).
For an overview about what klik is and what it isn't see this intro-
ductionary article of mine:
http://dot.kde.org/1126867980/
For some quick answers to FAQs see this link:
http://klik.atekon.de/wiki/index.php/User's_FAQ
> > The klik way of obtaining packages seems to have solved many other
> > problems related to package management as well, so this is something
> > Debian developers should study carefully.
I disagree in that rather drastic and absolute-ish notion of this
statement from the initial poster...
First, klik is not a package management system at all. It doesn't
strife to replace apt-get, dpkg, rpm, yum, apt4rpm, smart, autopackage
or what-have-you.
Second, klik is (IMHO) only in "usable beta" stage. (But I of course
agree that klik has some very nice, very beneficial use cases -- use
cases that benefit endusers as well as developers. See links given
below.)
Why is klik not a "package manager"?
First, because klik does not interfere with any host's base system. It
does not install into /usr. It does not mess up your native package
manager.
Second, because klik "packaging" does not (as a rule) involve to build
from sources, does not involve compiling. It merely "repackages" what
has been packaged by real men such as you. ;-P
And third, klik doesn't really "install". It brings exactly 1 additional
file (the *.cmg) onto the system. It works with "user only" privileges.
It is a self-contained bundle encompassing all the direct depencies
(however, it expects certain "base system" libraries and utilities to be
present on the system).
> Do they solve any of these problems better than Debian does?
You did not name "these problems".
What *I* personally use klik for is this:
* using (for testing, bug-reporting, translations, etc) "bleeding
edge" versions of software on my system (side by side with the
system-installed stable versions) without endangering the stability
of that base system in any way.
* using different versions of the same software side by side without
having to mess with the system package manager.
* testdriving new versions of software before deciding for an
upgrade of the system-installed package.
klik bundles:
- are easily relocateable (run them from $HOME, from an USB stick or
even directly from CD).
- are to a degree even transferable between different systems (well,
we have to suffer from GCC and C++ ABI incompatibilities too).
- implement an "1 file == 1 application" paradigma, which makes it
much more easy to handle by even "grandma" users.
- do not pretend to be something completely new -- NeXT and Mac OS X
had/have something very similar in the shape of "AppDirs".
The only new things brought by klik are
a) compression of the AppDir into 1 single file system image, and
b) offer klik bundles via a web service
> Would
> Debian users derive any value from klik?
The same as I do (if they are interested in it).
But klik also offers interesting use for *developers*. One of these
you will probably see emerging in the next couple of weeks when the
KOffice-1.5.0 version approaches final release. We will be providing
easy to use and test klik bundles, that should run on all $debian
systems, plus some RPM-based ones too.
> How?
>
> If not, I fail to see why Debian should care. We've got enough to
> worry about just making packages suitable for Debian - why go out of
> our way to help people who refuse to use Debian?
We are not refusing to use Debian ;-)
In fact, (official and unofficial) Debian package repositories are
the main source of input files for klik users. Without the hard and
good work made Debian packagers klik would be *nothing*. It would not
exist.
klik.atekon.de (the server which holds the klik recipe database) is
internally driven by apt logic ("server side apt") -- and this is
acknowledged on almost every single page on this web server.
klik started off as a way to add more packages to Knoppix (and later
Kanotix too). The first bundles were KDE based. The name stems from
"KDE-based Live Installer for Knoppix". This name's scope is now long
outgrown -- klik works for Gnome too, with Gnome packages, and with
some more than only Knoppix or Debian distros.
To quickly test it (for the fearless amongst you), install the klik
client (20 seconds effort, 20 kByte download); run in an xterm, konsole
or similar this command:
"wget klik.atekon.de/client/install -O - |sh"
and follow instructions on screen (read the "Dot" article mentioned
above if you want to know what will happen without needing to reverse
engineer klik).
However, *most* klik recipes use Debian packages as input files -- but,
there are some exceptions, which use RPMs, .tgzs or other if we could
not find a recent enough Debian version on the web, or if the app in
question is a development version, such as
klik://inkscape-latest
klik://xara-latest
klik://scribus-latest
klik://krusader-cvs
klik://amarok-svn-nightly
klik://flock
klik://thunderbird16-tabbed
klik://wengophone
etc.
> Peter
Sorry if you feel bothered, Peter.
But still, it may be worth to have a closer look at what klik can do
for people using Linux (yes, including "newbie" end users; but even
more what it can do for developers during the development cycle -- this
includes coders as well as the "non-technical" contributors like beta
testers, documenation writers, translators, usability experts...).
Cheers,
Kurt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
