Apps :: How has the extensions framework changed?

Regarding this whole "/var/tmp" thing, could this big incompatibility problem be solved simply by adding an extra (mostly superflous) tiny symlink to the bootup for DSL version 3.01:

/var/tmp -----> /tmp

(and of course /tmp already links to /ramdisk/tmp so the "broken" extensions would start working again).

Just a thought. Don't have 3.x loaded right now, so I can't test it.

Linking into and from unionfs can sometimes cause system hangs.
Otherwise I suppose Knoppix would have done this.
It is ok for Knoppix proper to move forward with this change, but not DSL?
Sometimes it is not easy to always support the old. If it were only that simple, it would have been done. Adding unionfs is complex enough. It is just as simple to try to keep things clean and tidy. Being less complex should always be a goal. I found not only some linking but also some mounts (nfs and smb do not always work across unionfs either. But those type of mounts are not really necessary, just as these symlinks. Better to KISS than to crash and wonder why.

mostly you only lose your menu shortcuts. it's not a big deal unless the apps have no desktop icons either.
You can create desktop icons, which are permanent in .xtdesktop. Speaking of which, should we come up witha set of 'standard' icons (ala 'moricons' )?

The more I think of it, the whole

/var/tmp -----> /tmp

link should not become the standard mode of operation, and instead should only be used as a temporary workaround until the broken extensions are fixed. (That is, assuming that it even WORKS. Still haven't tried it yet).

Why?

Because extensions should never have "tarred" filename paths that begin with /ramdisk/tmp/xxx or /var/tmp/xxx

These bad extensions would also be problematic when someone tries to use them with a traditional hard disk installation instead of a livecd configuration because with a hard drive based filesystem, /tmp is neither located at /ramdisk/tmp nor at /var/tmp

So the right thing to do is identify the "broken" extensions and request that the contributors fix them.

On a positive note, any extensions created with "deb2dsl" should not suffer from the /var/tmp or /ramdisk/tmp problem.

Quote (cbagger01 @ July 06 2006,00:10)

These bad extensions would also be problematic when someone tries to use them with a traditional hard disk installation instead of a livecd configuration because with a hard drive based filesystem, /tmp is neither located at /ramdisk/tmp nor at /var/tmp

I haven't used a traditional harddrive install, but i can't see why /var/tmp would not work in pre-3.0 installations. In the earlier versions of livecd/frugal DSL /var/tmp was the true directory, and /tmp was a symlink to /var/tmp....any reason it wouldn't be the same on hd? Some might look at that linking to mean that /var/tmp is the appropriate directory to use. I thought that for a long time, before realizing the flaws in my logic.

Next Page...
original here.