Making smaller, smarter kliks

[Donn]

I suspect I will get flamed for this heretical suggestion, and I did search around the forum to see if it had been suggested before but I could find no signs.

Let me start by saying that I *do* get the Klik concept. It's as startlingly simple as it is to use. Amazing and it's a real gem in the Linux crown!

Now, onto the thing:
What if Klik could search the system for libraries (and whatnot) that are *already* installed?
If so:
1. The stuff that needs downloading could be lessened.
2. You could have a more efficient way of installing software (less hdd space used etc)

Example:
A klik URL is clicked
It fetches its list of ingredients.
It checks the system to see what is *already on the system*
It makes sym-links within the .cmg to the system files already available.
It fetched those files that *are not there*
It runs the app.

This would cover the situation when you move the .cmg file to another system and that system does not have all the needed libraries. The Klik would then *freshen* the .cmg file with the needed stuff.

You could also have a .cmg that contains the common libraries (and it can grow per klik) so that the other klik files would sym-link into it for their common libraries. Common libraries could be marked as such over time (lke Qt and GTK etc) so that they don't get downloaded again and again and again.
(In fact libraries that are already on the system could be *copied* into the common.cmg so that they can move wherever it goes.)

This way, you would still divorce the klik apps from the system, but you would maximise the sharing that could be done and increase the efficiency and reduce the bandwidth needs.

I do see that it begins to blur with yum or apt-get at this point, but it's still as simple as a klik URL and it's still clean and separate from your actual system's files.

You could also produce Klik DVDs and CDs with loads of "run-anywhere" (on Linux) software on them because they would not ALL be reproducing the same shared code again and again.

Well, that's my 00001010 cents.

[alexey_]

actually, searching is easier said than done. In reality in different distros, same libs might have different names/versions/paths/etc...
What we do now (on SUSE, at least) is symlinking the pseudo-Debian libs to real SUSE libs, so we save space.
But your approach may be more scalable.

Searching can enchance klik very much, and I would be garteful to you, if you cooperate on implementing it to klik.

[Donn]

alexey_
I have a bunch of questions, but I don't want to waste your time, especially when I have so little of my own! I have been meaning to look at the Klik code to see how the magic is done, but I have just not had two minutes to rub together!

One thing occurred to me: ./config
When one installs (most) anything from source, you run that script - and it magically tests for all the libraries that it needs (cross-distro). Perhaps the answer to the 'search' part of the equation is in there somewhere. (The small C apps that query the libraries directly etc.)

Each Klik package "knows" the versions of libs etc that it needs. One of the first 'ingredients' could be a set of scripts that are tailored to that package that know how to find the libs it needs.

I apologize for not being more helpful - hack on in peace!

[probono]

Let's not talk about the current status, but about the long-term vision:

The goal of klik is to have _one_ cmg that can be run on _all_ distros that are compliant.
For this, we need to make Linux a "platform", like Mac or Windows are (known set of core libraries and applications that are part of every system). The Linux Standards Base Desktop is a project which works on this already.

So the goal is really to have "universally portable" cmg files. Even if they are a bit larger than they would need to be for one particular system.

Advantage: You can have _one_ cmg that runs on _any_ klik-compliant base system. Just copy to another machine, runs.

(We're not there yet completely, granted - but we one day will...)

Greetings,
probono

[Donn]

probono -
I understand your desire to have a 'standard' Linux. I really wish there was such a thing. I don't know if there really ever will be, though.

I think something like Klik has the opportunity to bring some of that 'universality' to Linux.

It could be an entire run-time software system that sits on top of any Distro and makes sure that it is coherent within itself. It would perform tests (by whatever means) to ensure that it has all it needs to run any package.

As I suggested in my OP, there could be a "common.cmg" - which Klik could put into /etc/klik, for e.g - which contains all the libraries and common "stuff" needed. It would grow (and shrink) and all the other Kliks could link into it.

I don't know if this is incompatible with the Klik vision, but it sure would be nice if I could run an app from a Klik repository and then suggest the exact same URL to my friend on another distro and have them run the exact same file. Wowee!

[alexey_]

Donn: I have a similar vision.
All:
I think, that by doing such a "common.cmg" we could offer klik with *ful* functionality (which means KDE,GNOME,...) even to mini-distros like Puppy Linux. (provided that a common.cmg is big enough of course...)

But a "common'cmg" might be big only on min-distros like Puppy, while on a full-featured systems, like SUSE, it will basically include just the symlinks to SUSE libs, and Debian's libc++5 which will result in very small file (few hundreds of kilobytes).

That way, we *can* build a "common" klik runtime for multiple Linux distros.

Perhaps, those "common" runtimes must be tuned manually for each Supported OS. So this will result in "extra" work, but in turn it will provide us with fantastic-high klik suceess-rates.

P.S: Of course after LSB for Dekstop will be applied to all major distros, we will drop this "common" klik runtime.
But for the next-year it will be very needed.

[probono]

LSB-Desktop is what you want

[alexey_]

Of course LSB-Desktop is what I want ! Damn !

But we can't wait for 2 years or so until the standard is finalized and gets into Debian-Stable & other distros !

We need a quick solution *now*.

[Lews]

Being able to detect which libraries are required to run a program is not very hard. All distributions come with ldd, and with a little shell scripting you can parse its output to find any missing libs. What would be needed is a per-binary manifest of libraries, and where each library can be found. If any missing libraries are detected in the program, the required package is downloaded and added to the .cmg.

There are some problems with this. Some libraries depend on other libraries...for example, GTK+ 2.8 depends on Cairo. If the user has damaged their system in such a way that GTK+ is installed, but Cairo isn't, programs with their manifests created on a pre-2.8 system will think they have all required libraries but still fail to run (of course, no GTK programs will run). In this case, Klik should just download everything it can and try again (no way to tell which library has missing deps, or where to get the deps).

Here's a small shell script to check for missing libraries. Pass it the name of a program, and it will output the names of any missing libraries and return the number of names found. If there are no missing libraries, it will return 0.

#!/bin/bash
libs=$(ldd $1 | grep 'not found' | sed s/'\t\(.*\) => not found'/'\1'/g)
lines=$(echo "$libs" | wc -l)
echo "$libs"
exit $lines

[Lews]

So, are there any plans to get this into klik? The current method of downloading dozens of libraries your system already has is a bit of a PITA.