CDE portable apps

[Jason W]

This is a utility to make a very portable package out of any app.  I tried it out on emelfm2 and abiword, and simply running "cde emelfm2" makes a fully self contained package, basically including whatever is used and needed in a directory structure under a cde_package directory.  It works with our tcz symlinks as it includes the target files in /tmp/tcloop.  Not for making distribution packages with, as the cde binary is needed to run the resulting app.  But nifty if you want to quickly package up your favorite app from one distro to be able to be run on any other.  And Tinycore is given a mention on that project page.

http://www.stanford.edu/~pgbovine/cde.html

[vinnie]

that's great!
I could use to create packages scm after creating the TCZ?

[Jason W]

It won't create an scm, but does create for one's personal use an app directory that contains all needed dependencies, even ld-linux and the low level libs, so it will run on any other distro.  An scm installs into /apps only, and includes just the higher level dependencies.  Whereas a package created by cde is truly portable, run from any directory location on any distro.

[gerald_clark]

It sounds like a cdetoscm utility would be pretty simple.

[Jason W]

Actually, I will play with a package or two and just for fun upload them to the scm directory.  There is one binary, cde-exec, that is used during runtime, cde binary creates the package by simply just running "./cde leafpad" to create a full leafpad package. 

[Jason W]

Actually, running the apps through the cde-exec tool means a slow down, as well as the package is run with basically a chroot into the package root directory.  Which means no seeing you wider system area through the app. 

Otherwise, does great at gathering up what is needed to run and packaging it into it's own directory, useful for specific purposes.

[Jason W]

Ok, not all is lost.  A symlink named sysroot pointing to / allows data access at least.  I am uploading abiword-cde.scm and a couple others to play with. 

[vinnie]

It won't create an scm, but does create for one's personal use an app directory

is a real shame, a system of automatic creation of SCM by cde would create very beneficial.
Those that come to mind:
-do not need another repository (with larger packets of TCZ)
-no need to create two versions of the same package by the packager
-a wide range of programs immediately (with the possibility of extending a hypothetical cdetoscm.sh script on other distros like debian)
-freedom left to users to be able to create their own extensions independently

I also made a small diagram because it inspired me a lot

[Jason W]

Though this post is no longer related directory to CDE, after reading up on the methods that are used in making portable apps, I have made some headway on how to take existing apps and making a self contained app out of it.  CDE does a good job of gathering most if not all of what an app needs to run, and then some adjustments can be made to the binaries to make them look into relative instead of hard coded paths.  Thus being able to be unpacked anywhere and run. 

There is a prototype emelfm2 named emelfm2-portable.tar.gz in the scm source area that should run when unpacked into any location.  Run the emelfm2.sh in the top directory, should work with 'base norestore'. 



Though scm's don't need to be truly portable, if one wants to be able to make a standard app plus dependencies into an scm, then the portable part has to happen.  portablelinuxapps.org and it's documentation has been very helpful.  I prefer myself to make a true scm compiled into /apps, but maybe a method can arise to allow make a self contained package out of what has already been built.

[vinnie]

Thanks Jason, I estimate you very much