Luca Cappelletti

this is one of my old way to solve thinks taking into account an evolution starting from ROX AppDir, OSX Bundles/DMG handling, Klik gateways and others.
I explored also an os centric mode with mount bind into a live tmp filesystem but everything pass through the root…and it’s bad for me.
I’m working now into a solution that does not take into account of oscentric and esoteric out of rootless peoples control.
My vision is 100% user centric.
To let you understand what I’m going to do just point to some of my experimental packages here:
Oldest one: http://sourceforge.net/project/showfiles.php?group_id=43393&package_id=151348
Newest one:
http://sourceforge.net/project/showfiles.php?group_id=199098
Whith what I’ve renamed as “SpatialBundles” I’ve no requirements other than: Bash.
So no root, no fuse, no tmpfs, no mount.
Nash it’s not a striclty requiremente in the future because for performance reasons I can choose to use and ELF file directly like glik but my point of view in terms of usability take into account to let better developers to manipulate directly the Bundles using the standard bash shell.
My technology now use directly Makeself to make a single file runnable where there is embedded al what I call as “CrossBundles” that let me run the bundle on a Linux/BSD/OSX platform depends on how I ‘bundled’ the runnable objects.
This days I’m solving newer issues to permit a good mime interaction bundling Java6 with very good and promising results.
My technology it’s not so publicy available because I’m trying to develope a tool to permit developers to freely build their own packages without lost into the developing tools world as you can do into a generic tool like *pkg*, xcode, and so on…trying to reduce to the max complexity and offer to developer something so banal tha should be 100% transparent…
The skeleton of my SpatialBundles are made by a nativa recompilation against:
/tmp/Programs/
than repackaged with Makeself to make single file runnable where it acts as a gateway if there where a previous run (speeding up the run) or,as Makeself do, extract into /tmp/Programs and then run the main binary.
Peoples manipulate spatially the original Bundle doing thinks like, duplicate, sending via mail/bluetooth etc etc, renaming, trashing…nothing is installed, nothing require installation and a two fase turbo cache (disk and ram) could be activated to improve future runs into a os restart session.
After the first run the Bundle is shared with al the system user so they could feel and improvement of speed for their first run…
I’m working to better thinks and include features…it’s just a matter of time

In the mean time you can simply reverse packages due to it’s native Makeself-ish
Hope next day could give you more.
Tnx to Alexander for your work,

Luca Cappelletti

Imho the only unclear point is the desktop file/ icon issue. Maybe a workaround is an option, for example the app provides an option to install the desktop file and icon to ~/.local/share/ along with a subtle uninstall option, similar to what autopackage does. In any case this is a minor problem imho, since we don’t want long-time users anyway but rather encourage users to use the distribution package of a stable version if they are going to use it more often.

“Hopefully the klik people will look at my work and steal the appropriate ideas.” –> We’d definitely like to invite you to our next developer meeting (http://klik.atekon.de/wiki/index.php/Developer_meetings), and to #klik on freenode. This invitation also extends to other interested developers (= all frequent readers here).

As for the “k” in klik, it is no longer specifically related to KDE. We do have GNOME and CLI interfaces Today, “klik” has no special meaning besides its resemblance to “click”.

Again, “hats off”. I’m going to test it now…

Another way to make an application relocatable is to use our binreloc code (http://www.autopackage.org/docs/binreloc/). We have two versions, one that require some code changes, and one that uses a dynamic prefix through the proc filesystem. Linux only though.

As Joe Shaw experienced, there are more problems with shipping distribution neutral packages than wrapping them in a container and making them relocatable. The binary incompatibilities between distributions, and even versions of distributions, requires compilation tweaks to make it work. libc and gcc does not support “build once, run everywhere” out of the box, and there’s tons of “Oh-by-the-way”’s to consider. For Autopackage, we have developed and use APBuild (http://www.autopackage.org/aptools.html) which is a perl script around gcc/g++ that addresses many of the issues.

For self contained apps, the appfolder style bundle is quite useful, but as soon as the apps depend on each other (e.g., plugins) or it contains files used by the system such as dbus session files, fonts, images/icons, desktop files) it needs to go to a location where the system can find it.

That’s enough pessimism for now, and all things considered, I think this is a very cool investigation project!