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