KlikIntegration
Size: 4445
Comment:
|
← Revision 19 as of 2008-08-06 16:34:38 ⇥
Size: 7883
Comment: converted to 1.6 markup
|
Deletions are marked like this. | Additions are marked like this. |
Line 4: | Line 4: |
* '''Created''': [[Date(2006-01-25T02:52:56Z)]] by Merc2 * '''Contributors''': Merc2 * '''Packages affected''': |
* '''Created''': <<Date(2006-01-25T02:52:56Z)>> by Merc2 * '''Contributors''': Merc2, RaphaelPinson * '''Packages affected''': fuseiso, fusecram |
Line 13: | Line 13: |
Line 15: | Line 16: |
At the moment, to install an application a user needs to use Synaptics. This means that s/he will need root access, AND that the package will need to be available in one of the repositories. | * At the moment, to install an application a user needs to use apt. This means that s/he will need root access, AND that the package will need to be available in one of the repositories. |
Line 17: | Line 18: |
* Currently, most klik packages are based on Sarge. Hence : * Most programs are more recent in Ubuntu stable than in Sarge. * These packages are built on libraries on which Ubuntu might have overtaken transitions (e.g. libstdc++5 in Sid vs. libstdc++6 in Dapper). * Security updates in Ubuntu might not be followed in Klik packages. * We have no direct control on the Q&A of the packages provided by klik. * Klik vs. Backports |
|
Line 20: | Line 28: |
* A user wants to install an application without having root access to the system | * Sven wants to install a program on his work machine but has no administrator access to the system. |
Line 22: | Line 30: |
* A user wants to copy an application onto a CD, and be able to run it off the CD without installing it | * Clara has a program she likes very much but few people have installed. When she moves to another machine, she'd like to take this program on a removable media or a CD and run it from this media without installing it. |
Line 24: | Line 32: |
* A user wants to install an application that is not available in any repository | * Paul wants to test the latest version of a program, but this program is not available in the apt archives yet. * Mel administrates a stable Ubuntu system. She wants to provide a test version of a program to all the users of the system, but there is no package available for her version of Ubuntu. She could install cmgs in /opt. * Marc and James installed Feisty Fawn to recognize that Thunderbird 2.0 isn't available there, and so they have to wait another half year until it is available. Marc knows who to install Thunderbird manually in his home directory. James doesnt know how to do that, so he needs a easy way to achieve that without being bound to release schedules. |
Line 31: | Line 43: |
Line 33: | Line 46: |
Please have a look at [ this interview http://www.freesoftwaremagazine.com/free_issues/issue_11/simon_peter_interview/ ] for more information about Klik (straight from the author!) | * Packaging : Currently, the klik installer installs invisible scripts in ~. We don't want this behaviour. Instead, these scripts should be made system-wide and installed in /usr/bin. |
Line 35: | Line 49: |
Basically, Klik is "ready to go". What is missing, at the moment, is: | * FUSE Support : Klik uses cramfs. Currently, the installer adds dirty mounting points in /etc/fstab. FUSE could handle mounting cramfs without having these entries in /etc/fstab. The recent kernels shipped with Ubuntu have FUSE support. We need to find a way to activate the FUSE module cleanly. fuseiso and fusecram are then required to use klik with FUSE support. These packages are already in Dapper. The klik scripts have to be reimplemented to use FUSE. KANOTIX has done so lately. |
Line 37: | Line 54: |
* A way of "registering" where an application is. An application could be registered the first time it's run (as it happens is OS X). Then, if it's moved by the GUI, it could re-register itself in the new location | * A way of "registering" where an application is would be good. An application could be registered the first time it's run (as it happens is OS X). Then, if it's moved by the GUI, it could re-register itself in the new location |
Line 39: | Line 56: |
* An EASY way of assigning mime types to a registered application. | * An EASY way of assigning mime types to a registered application. |
Line 41: | Line 58: |
Both these modifications would be fairly easily achieved by patching Nautilous. | * Patching nautilus and firefox to get support for the klik:/ protocol. |
Line 44: | Line 61: |
Line 49: | Line 67: |
* Patching nautilous so that it registers applications. This should be done in such a way so that Konqueror for example does it in a compatible fashion | * Patching nautilus so that it registers applications. This should be done in such a way so that Konqueror for example does it in a compatible fashion |
Line 52: | Line 70: |
Also see [[http://klik.atekon.de/wiki/index.php/Dapper]] |
|
Line 83: | Line 103: |
Allo says * There is no problem with apt apps. if you klik foo.c3 - mg or run cmgrun foo.cmg, you execute the klik app, if you run "foo" or "/usr/bin/foo", you run the apt-installed app. * I think, the concept of downloading a shellscript and executing it, is wrong. klik should only transfer metadata, and have its scripts locally to build a cmg from some debs/rpms. But its not so dangerous, since it does not run with root access. Robert says * Point 2 is not an issue for the most important use cases which Klik facilitates since the software is installed in the user's own directories and doesn't interfere with apt. Ditto for Point 1. * Re: Point 3. apt / dpkg etc. are all part of the same system, and they have the same problems. Namely that it is not possible to install software without being root. The concern about whether Ubuntu has 'control' over a particular software installation method irritates me - the user's freedom is the raison d'etre of free software. The most basic freedom being to run a program as you wish ( and that applies to people who do not have the technical skills or time to download the sources and try to build it themselves ). * As a developer, it is important to me that I can get feedback from user-visible changes in my application as quickly as possible, which means making very recent builds of software available for people to run and test. Making non-technical users wait six months before they can get their hands on a new build is very inefficient. Even for technical users, the time cost of downloading, compiling and getting development builds to run is high enough that it poses a serious barrier. |
|
Line 84: | Line 113: |
Line 89: | Line 119: |
* http://revu.tauware.de/details.py?upid=2824 |
Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/klik-integration
Created: 2006-01-25 by Merc2
Contributors: Merc2, RaphaelPinson
Packages affected: fuseiso, fusecram
Summary
I believe it's very important to integrate Klik and Ubuntu as much as possible. Klik offers a way of installing applications in GNU/Linux without actually using a repository. It's based on the "Appdirs" specifications.
Rationale
- At the moment, to install an application a user needs to use apt. This means that s/he will need root access, AND that the package will need to be available in one of the repositories.
- Currently, most klik packages are based on Sarge. Hence :
- Most programs are more recent in Ubuntu stable than in Sarge.
- These packages are built on libraries on which Ubuntu might have overtaken transitions (e.g. libstdc++5 in Sid vs. libstdc++6 in Dapper).
- Security updates in Ubuntu might not be followed in Klik packages.
We have no direct control on the Q&A of the packages provided by klik.
- Klik vs. Backports
Use cases
- Sven wants to install a program on his work machine but has no administrator access to the system.
- Clara has a program she likes very much but few people have installed. When she moves to another machine, she'd like to take this program on a removable media or a CD and run it from this media without installing it.
- Paul wants to test the latest version of a program, but this program is not available in the apt archives yet.
- Mel administrates a stable Ubuntu system. She wants to provide a test version of a program to all the users of the system, but there is no package available for her version of Ubuntu. She could install cmgs in /opt.
- Marc and James installed Feisty Fawn to recognize that Thunderbird 2.0 isn't available there, and so they have to wait another half year until it is available. Marc knows who to install Thunderbird manually in his home directory. James doesnt know how to do that, so he needs a easy way to achieve that without being bound to release schedules.
Scope
- This only covers software installation WITHOUT using Synaptics.
- Klik is NOT a replacment for Synaptic
Design
- Packaging :
Currently, the klik installer installs invisible scripts in ~. We don't want this behaviour. Instead, these scripts should be made system-wide and installed in /usr/bin.
- FUSE Support :
Klik uses cramfs. Currently, the installer adds dirty mounting points in /etc/fstab. FUSE could handle mounting cramfs without having these entries in /etc/fstab. The recent kernels shipped with Ubuntu have FUSE support. We need to find a way to activate the FUSE module cleanly. fuseiso and fusecram are then required to use klik with FUSE support. These packages are already in Dapper. The klik scripts have to be reimplemented to use FUSE. KANOTIX has done so lately.
- A way of "registering" where an application is would be good. An application could be registered the first time it's run (as it happens is OS X). Then, if it's moved by the GUI, it could re-register itself in the new location
- An EASY way of assigning mime types to a registered application.
- Patching nautilus and firefox to get support for the klik:/ protocol.
The tricky part would be the creation of an applet that checks that each registered application is indeed up-to-date. This is much trickier, but still not impossible to achieve.
Implementation
The coding involved would be:
- Patching nautilus so that it registers applications. This should be done in such a way so that Konqueror for example does it in a compatible fashion
- Writing the applet that works on the updates
Also see http://klik.atekon.de/wiki/index.php/Dapper
Discussion
Daniel-Goldsmith says:
It seems to me that system-level Klik integration may be more trouble than it is worth. This occurs for three reasons:
- Incompatibility of Klik-patching with standard ubuntu patches in libraries. This would result in Klik'd libraries failing to function with ubuntu patched programs installed at a later time from repositories.
- Incompatibility of Klik with apt system. This would perforce lead to difficulties in supporting users who had klik'd their systems by installation of items with compatibility issues, thus preventing ubuntu achieving enterprise usage.
- Already there are a multiplicity of Ubuntu upgade/installation systems. Just on a quick memory count the user can apply dpkg, apt-get, aptitide, synaptic, adept and Ubuntu's own 'Add Application. Do we need a further method, particularly one over which Ubuntu has little or no control?
Tony Mobily says:
I don't think point 1) is valid, but I am not 100% sure. Points 2) and 3) are definitely valid.
However, do you have a counter-proposal for a system which:
- Would allow people to install software as non-root (or non-admin)
- Would allow people to see a program as in "icon", and copy such a program on an external media and _run_ it
...? I see these two things as crucial. Mac got it right. Linux... not quite :-|
Klik is the closed thing there is to a "solution". The points (2) is very true. However, I think (3) Is the real problem: it doesn't have *much* to do with Ubuntu. However, Klik is there and it works...
KillerKiwi says
- Points 1 and 2 is a non issue also as klik apps do NOT afect the system in any way
Point 3 - There are many systems but i dont think any of them meet the 'human' need, dont belive me check this out http://www.whistlerquestion.com/madison%5CWQuestion.nsf/0/A0DA1F88D3FCB4DB882571250004E6E3?OpenDocument
- Other, An Application Folder type system might be a solution for registering menu/mimetypes
Allo says
- There is no problem with apt apps. if you klik foo.c3 - mg or run cmgrun foo.cmg, you execute the klik app, if you run "foo" or "/usr/bin/foo", you run the apt-installed app.
- I think, the concept of downloading a shellscript and executing it, is wrong. klik should only transfer metadata, and have its scripts locally to build a cmg from some debs/rpms. But its not so dangerous, since it does not run with root access.
Robert says
- Point 2 is not an issue for the most important use cases which Klik facilitates since the software is installed in the user's own directories and doesn't interfere with apt. Ditto for Point 1.
- Re: Point 3. apt / dpkg etc. are all part of the same system, and they have the same problems. Namely that it is not possible to install software without being root. The concern about whether Ubuntu has 'control' over a particular software installation method irritates me - the user's freedom is the raison d'etre of free software. The most basic freedom being to run a program as you wish ( and that applies to people who do not have the technical skills or time to download the sources and try to build it themselves ).
- As a developer, it is important to me that I can get feedback from user-visible changes in my application as quickly as possible, which means making very recent builds of software available for people to run and test. Making non-technical users wait six months before they can get their hands on a new build is very inefficient. Even for technical users, the time cost of downloading, compiling and getting development builds to run is high enough that it poses a serious barrier.
Links
http://klik.atekon.de/wiki/index.php/Dapper
Code
Outstanding issues
BoF agenda and discussion
KlikIntegration (last edited 2008-08-06 16:34:38 by localhost)