Method to use extension files without external links.

[SunBurnt]

I thought to put this in the extensions forum, but it`s the core that makes it work.

The drill...
Mount the extensions and in a script running a new shell, make a new $PATH into it.
Then the script runs the app. and it should work, only writable files need to be external.
The config. files have to be written to, so these files inside the extension file are links.
The config. links point to persistent storage of course, through a main /etc link in ram.
Having the main /etc link in ram allows it to point to the selected partition for storage.
The config. files would be in a special dir. in the extension and copied to the storage.

So then there`s no links outside the extension file that mirror files inside it.
However there are config. files outside it, but it`s a necessary evil, as it is in TC now...

This means that the apps. in the extension files must have their writable files doctored.
In tests, simple apps. worked with no modifications, bigger apps. need more work.
This is the down side, the current TC extensions need no doctoring to work I believe.
Currently making new extension files is a utility to extract and Squash them. ( I believe )

[curaga]

What about command line apps? There are limits to env vars, PATH can't just grow for each extension. Nor can you change PATH on a running session.

Or do you mean to auto-generate a script for every binary? That's way more wasteful than a symlink.

[SunBurnt]

Cli apps. can run from a script also, script sets the path and runs Aterm, or the app. directly if no user interaction`s needed.

Scripts could be auto generated, but making them ahead of time and putting them in the Squash file seems better.

[curaga]

I don't understand. If the scripts are _in_ the extensions, then how can they be called without symlinks or path changes?

Perhaps you should've posted code. It's really not clear what you mean to do and why.

[jur]

So this eliminates the loop mounting and symlink-making that is currently used? Is it faster?

[Jason W]

If extensions were self contained apps where everything they need outside of the base iso was in the extension, this method would work, and has been used before.

But for our shared library approach, it would make for a big mess to try to set hundreds of different paths, if it even could be done as all the scripts that are mentioned here would have to be regenerated every time an extension was loaded.  Or they would have to come premade with the path to every dependency already there, and hope that nobody ever changes extension names.  And I wouldn't want to think about trying to compile something in that environment. 

If extensions were much less factored, say all of qt was in one extension, all of kde in another, or all of gtk2 and its dependencies were in another, it can be and has been done.  But that is not now we are set up now.

[SunBurnt]

Jason W. has it exactly correct. The extension packages would really need to be more "self contained".
It`s not that it has to be done this way, but for apps. that use lots of dependencies it could get messy.

I`ve never seen an analysis of the size difference between apps. compiled alone and with dependencies.
Obviously apps. with many dependencies will be larger. But statically compiled apps. have advantages.
Much like the tracking of files in apps., the same for tracking the apps. dependencies, it`s not necessary.
And apps. with most or all of their dependencies self contained are apt to be less troublesome = stable.

A "hybred" method... Keep the large dependencies separate ( fewer of them ) and include the small ones.
This greatly reduces the "mess" and keeps the extension packages nearly as small as they are now.

As I said... The need to "doctor" the extension packages in itself is enough to make this method difficult.
As TC is now, I think extensions are made directly from Debian ( or ? ) packages with no changes at all.

curaga; There are many different ways this can be done of course. Auto generation, pre-made, etc.
My thought was; In each extension file a dir. /Setup that contains a script to setup the extension for use.
Once the extension file`s mounted it`s easy to access the script in /Setup as it`s always in the same spot.
All the config. files that need to be copied to persistent storage are in /Setup also, and any external links.
External links are needed for apps. that are called by other apps., so need their "exe" file to be in $PATH.

Much can be done changing $PATH, but I don`t think it`s necessary. And I don`t like lengthening $PATH.

As said... An alternative method of what TC does now. Whether or not it`s better is opinion of course.

[Jason W]

The firefox's, xine-xvesa, and a couple others are made similar to what is being described here.  With xine-xvesa, I installed it into it's own directory, /usr/local/xine-xvesa, so it does not collide with or prevent another xine extension.  That way, others are free to make their own xine, and I can heed or not heed an update request as nothing will depend on my version, I can update it when I want.

They are not totally self contained as they require outside dependencies.  And though this is an option for end use apps, it obviously is not a good way to install libraries that other extensions will need.