make most debian software klik-able (alpha)

Hi all,

I'm working on serverside-apt, the goal of which is to auto-generate klik recipes on-the-fly so that one day, all software that is in debian will be klik-installable without further manual intervention.

In principle, it already can be done, which I am showing below. In fact, most debian KDE apps work right now! In reality yet, there are still many obstacles to be solved.

You can try what already works:
klik://kino - video editor
klik://bidwatcher - eBay sniper
klik://sim - ICQ client
klik://kbabel - translation
klik://gkrellm - system monitor
klik://nmapfe - nmap frontend
klik://keduca
klik://kmerlin
klik://kmoon
klik://bibletime
klik://kaboodle - multimedia player
klik://korn - E-Mail monitor

and even klik://trywhateveryouwant

Remember, the klik recipes for these installations are generated "on the fly" from the debian repository with serverside-apt. All of this is completely unsupported and just to show what is already possible.

Congratulations probono!

This is a giant advance for the live boot CD paradigm.

It combines an incorruptible base operating system
(except for the dog chewing on the CD)
with flexibility to easily add programs.

It may change the "ideal" content of the KNOPPIX CD to
focus more on libraries and the basic support programs,
but free up space since applications can be easily
added.

Can complex programs really be added on the fly?

Now for my 2 cents worth ;-)

To invoke a klik shell program one types:
~/app-name/wrapper app-name

Could you change "wrapper" to "go"
and teach wrapper how to find the argument app-name?

This trick should allow a script to get the name of its directory:

Code:

---

echo -n "AppName=\"`pwd`\"">&/var/tmp/AppName
. /var/tmp/AppName
AppName=${AppName##/*/}

---

Best Wishes,
paradocs

Quote:

---

Originally Posted by paradocs

Congratulations probono!
It combines an incorruptible base operating system
(except for the dog chewing on the CD)
with flexibility to easily add programs.

---

Exactly that is my intention. A rock solid, unbreakable "core system" that can be userland-extended with appications as needed without the risk of ever breaking anything. Personally, I have been using "poor man's intstall" of Knoppix as my main and single operating system for nearly one year now. I never had any problems with broken packages, forced upgrades and the like.

Quote:

---

Originally Posted by paradocs

It may change the "ideal" content of the KNOPPIX CD to
focus more on libraries and the basic support programs,
but free up space since applications can be easily
added.

---

Right. I think absolutely the same. The "core system" should be "stable" in terms of what packages it contains. In my opinion, it should include all the "low-level stuff" that is used in common by many applications, plus the latest KDE. It should also contain the larger "frameworks" (such as the LaTeX environment). Everything that is used by just a few applications instead could be klik'd.

Quote:

---

Originally Posted by paradocs

Can complex programs really be added on the fly?

---

In principle, anything (but kernel stuff) can. It really does not depend on the complexity of an app, but on how well designed it is. The least problematic are KDE apps. Nearly all of these can be klik'd without changes because they do not contain hard-coded paths. Instead, KDE uses variables such as "KDEDIRS", which can be easily set by the klik wrapper. Unfortunately, many other apps do include hard-coded paths, for example they expect a certain library in /usr/lib. The trick klik does here is to patch the binary to use ./../lib instead. This is a rather crude hack, but it does work for many apps. Some "frameworks" such as LaTeX are so reliant on hard-coded paths that I didn't get them to be klik-able yet. But in theory, there are no limitations.

What I really dream of: Convincing the debian developers not to accept hard-coded paths into the distribution anymore :) but I guess that will be a tough one...

Quote:

---

Originally Posted by paradocs

To invoke a klik shell program one types:
~/app-name/wrapper app-name

---

I know that is not ideal. The main problem is that many packages contain more than just one command line executable, and often the main executable does not even have the same name as the package (e. g. everything with "-utils" in its name). Please let me know if you find a solution for this.

klik right now is usable mainly for graphical apps. The typical command line user most likely knows how to use shell scripts in order t achieve his goals, or won't probably use klik in the first place. If he wants a klik'd command line app to be really "integrated", he will change /etc/profile or ~/.bashrc to include the PATH, LD_LIBRARY_PATH, MANPATH, etc. -> but this is not considered "professional" by some.

Since klik is KDE-focused, why don't we just make a menu entry for each command line app and open a konsole window? That's probably what I will do.

This thread may not be the appropriate place for my question (not sure...), but I'll ask anyway: Is there any possibility this concept can be modified to accomodate Win32 applications, for configuration under WINE? I see you have generic handler code for WINE apps at the software store, but most of the programs I desire are not yet klik-able (such as Exact Audio Copy, or VirtualDub).

- M.

Since there is no centralized repository like debian for Windows software (that I would know of), there is no way to have a genericized klik installer. Instead, a klik recipe has to be written for each individual WINE app. (Ideally, this involves nothing more than the URL of the installer...)

For ExactAudioCopy, you could try grip, klik://grip

For VirtualDub you could try the Linux app avidemux.
I didn't test klik://avidemux yet though.

Quote:

---

Originally Posted by probono

For ExactAudioCopy, you could try grip, klik://grip

For VirtualDub you could try the Linux app avidemux.
I didn't test klik://avidemux yet though.

---

While the cdparanoia libraries used by grip are good, the Exact Audio Copy verification routines are better... with the added benefit of an EAC user being able to properly calibrate the read/write offsets of their own drive, to ensure no lateral shift of the PCM data relative to the index points. (Grip/cdparanoia offers no such offset calibration, nor does any other Linux-based Audio CD ripping/recording utility to the best of my awareness. But even if the software did offer offset correction, I would still have a higher level of confidence in Exact Audio Copy.)

I need to investigate thhe relative advantages/disadvantages of avidemux. It may well be an acceptable replacement, although I would prefer to run VirtualDub under WINE; on the avidemux links page, the author even points out that VirtualDub "was the modele after which avidemux was made".

- M.

P.S.: For Exact Audio Copy there are four files which (ideally) should be scripted; two are static links to older versions (ZIP) hosted on the EAC site, and one is a dynamic link to the current release (also ZIP). The exception, and the version to script if only a single choice could be made, is unfortunately no longer accessible from the EAC website but permanently hosted in the ÜberNet.org archive as an EXE installer. Under WINE, Exact Audio Copy may still require an ASPI layer placed in the same directory as EAC.

Recommended installer:
Exact Audio Copy V0.9 beta 4 * recommended for most users (maximum functionality)
Nero ASPI Layer DLL

ZIP:
Exact Audio Copy V0.85 beta 4
Exact Audio Copy V0.9 prebeta 11
Exact Audio Copy V0.95 prebeta 5

Serverside app is not working for me. When I click on the link (like kino for example) it reports that klik is trying to run software on my local drive from an untrusted page. I select follow. It opens up a second tab in konqueror It then says klik is going to install software, and I choose okay. It pauses for a while then opens up a dialogue box that says "error while trying to run kino"

Any suggestions on what I might be doing wrong? I was able to install lphoto all right.

Please try another software. Also, please be aware that serverside-apt is very experimental right now. Does it work for anyone (besides me)?

Same error on all packages noted. I should comment that I'm behind a firewall, but (some of) the other klik packages install for me (i.e. lphoto, guarddog, gdeskcal, etc.)

Looking to hear from others regarding success /failure.

Regards,

~pau1

HI. Klik is cool but what about those of us that are allergic to KDE? We feel neglected I tell you! :) How can we help?

ProBono,

Not sure if you did something different, but it seems to really be working well now. I was able to add bibletime and a couple of other items. This is a VERY nice development.

Keep up the good work, and thanks for your time and efforts on this project.

Regards,

~pau1

More apps I just tested:

klik://gtkguitune
Guitar and other instruments tuner

klik://gtodo
GNOME to-do list manager

klik://hardinfo
Displays system information

klik://kanjipad
handwriting recognition tool for Kanji

klik://kbarcode
A KDE Barcode Creation And Printing Application

klik://lpairs
The Classic »Memory«-Game

klik://mgapdesk
X configuration tool for Matrox video card

klik://qps
Qt based process status

klik://regexplorer
Visual regular expressions editor

klik://rubrica
An addressbook for the GNOME desktop

klik://beast
music synthesis and composition framework

klik://camorama
Gnome2 tool to view, alter and save images from a webcam

klik://etherape
Graphical network monitor modeled after etherman


...and games: http://www.knoppix.net/forum/viewtopic.php?p=60026

Seems like IntelliPatch (patching binaries intelligently) really improves serverside-apt... :)

On http://klik.berlios.de there is now a technology preview of serverside-apt which offers all debian-apps with klik links.

Users have reported that the following work:

klik://airstrike
kik://junior-kde
klik://superkaramba
kik://lincity
klik://kworldclock
klik://ktron
klik://lgeneral (there are no games to load)
kik://xpacman
klik://xemeraldia
klik://vectoroids
klik://black-box
klik://electric
klik://ksimus
klik://pcb
klik://klogic
klik://karpski
klik://materm

Wonderful work, probono!

I noticed the serverside apt install of liferea works, however it installs .4.6, whereas the .deb on the liferea site is up to version .6

I don't understand how serverside apt works with regard to where it retrieves the .deb file, so my question is: would it be possible for me to modify anything on my system in order to install the more recent .deb file?

Hi redss,

currently klik uses snapshots from early this year as its debian repositories in order to maintain compatibility with Knoppix 3.3, which some people (including myself) consider the most usable.

I am working on a solution of this problem, but in the meantime, I don't know of an easy solution.

Greetings,
probono

I'm still a bit confused. I'm new to Knoppix and I stumbled across Klik when looking for an easier way to install packages, other than apt-get.

Question 1: Can users who install packages using klik update them using apt-get update or do you have to re-install a new version each time a point release comes out?

Question 2: If each directory has all the dependencies needed for the application to run, then I'm assuming that users who download packages using klik will have multiple instances of the same dependencies (as opposed to sharing them when using apt-get the traditional way), thus taking up more hard drive space, right?

Thanks in advance!

-Alexander

Quote:

---

Originally Posted by AlexSFBay

Question 1: Can users who install packages using klik update them using apt-get update or do you have to re-install a new version each time a point release comes out?

---

If you want a newer version of the application, you klik it again. Note that you can keep the old version and install the new cmg in parallel if you so wish. Each cmg is treated as an independent unit.

Quote:

---

Originally Posted by AlexSFBay

Question 2: If each directory has all the dependencies needed for the application to run, then I'm assuming that users who download packages using klik will have multiple instances of the same dependencies (as opposed to sharing them when using apt-get the traditional way), thus taking up more hard drive space, right?

---

No, each library that is in the base system is not installed again with each application (unless it requires a newer version than what is in the base system).

Quote:

---

Originally Posted by probono

Quote:

---

Originally Posted by AlexSFBay

Question 2: If each directory has all the dependencies needed for the application to run, then I'm assuming that users who download packages using klik will have multiple instances of the same dependencies (as opposed to sharing them when using apt-get the traditional way), thus taking up more hard drive space, right?

---

No, each library that is in the base system is not installed again with each application (unless it requires a newer version than what is in the base system).

---

So if a new library is required for a klik application, will it update the base? Or will klik have the newer dependencies placed in the program's directory and leave the old dependencies (later version) in the base for other applications? (I hope that makes sense -- my terminology may not be quite right)

klik never touches the base system (by design), so it leaves the old lib in the base system. This assures that klik never breaks the system.

Quote:

---

Originally Posted by probono

klik never touches the base system (by design), so it leaves the old lib in the base system. This assures that klik never breaks the system.

---

Sounds good! I guess if you're doing a fresh install of debian and KDE it would be good idea to stick with one format -- Klik being the easiest of the two -- to download applications. Too bad klik doesn't have have a function like apt-get that can update your packages across the board (aka all installed apps) in one quick swoop (would be a very cool feature).

[Thanks for the quick responses probono]

-Alexander