How to make SFS replace a file????

[mikeb]

The reality is that it solves the union shadowing problems that Puppy has always had.

yes what a dumb distro...why not just copy how slax layers then the problem disappears...

mike

[Moose On The Loose]

Moose; Don`t you think of a AppDir / RoxApp as a solution.?
The reality is that it solves the union shadowing problems that Puppy has always had.
And it also solves any possible library conflicts that`re a semi common Puppy problem.
I`m looking at making another of these apps., if you want help I`ll be glad to assist you.

The SFS that is giving me the direct layering problem is one that I am making for my own use. The idea is that I can put all of my favorite stuff into it and add it to the list of SFSs to be loaded at boot and have a system that with a totally new save file is just like I want it. This way, the system is very easy to take back to the "how I want it" state. All the pets I loaded to put in all the things I want will be part of the SFS. The save file is then just the changes from that point.

If the AppDir / RoxApp can be made to do this, I am very interested.

[Moose On The Loose]

The small script option has occurred to me, however it is far from a clean solution as it uses up personal save file space for each one of these I have to do. I may go ahead with the small script version adding the script to the profile.d to make it happen on stable boot but before the desktop.

You don't need pupsave file space - would be minor anyway. Just an idea: Can't you put your script into the SFS file? Either into /etc/profile.d or /root/startup? The script would reside on the SFS layer, so it would exist and run only when the SFS is loaded. Nothing to move, delete or check.

The script exists entirely to check and to move. This is what uses the space and not the script. I have a partial solution to the space consumption issue and the beginnings of the answer to the unclean issue.

Space reduction:
The replacement parts go in a different path than the normal ones and the script does a ln instead of a move. It then can check for the ln having been done before doing it again. The size of the link is small.

Cleaner version:
The script adds another script to init.d. Because this script got added, it will exist even if the SFS is unloaded. It can then detect that the ln has been done and points to a thing that is no longer in the system. If it discovers this, it can reach in slightly rudely and delete the "whiteout" information for the link in question and then suggest a reboot.

I still really don't like it but if the AppDir / RoxApp can't solve it, I may go down this path. When / if I figure it out, I may make a tool for others to use for this same purpose. (See other reply for what the purpose is)

[sunburnt]

An AppDir with many apps is the idea behind my AppPkg version of AppDir.
This would take going through each app and making it work in the AppDir.
Usually this isn`t too much trouble, some can be a real pickle at times.

What apps are in your SFS.? And it sounds like there`s some system files in it too.

Keep in mind my thoughts about apps and that there`s always a new one coming along.
So making the AppDir packages separately allows easy swapping out and merging of them.

A bare Puppy with utilities only, so it stays the same, while the apps are changed constantly.
.

[sunburnt]

Hey Moose; I`ve been trying to get a Chrome or Chromium AppPkg working.
It`s been such a mixed bag between web sites and SFS file problems.

# I`m hoping I can get a Chrome AppPkg uploaded to ally`s site.

# I made a Firefox-23 Virtual AppPkg here:
http://www.murga-linux.com/puppy/viewto ... 061#741061

# I`m wondering if you made a smaller SFS file with the apps that work.?
This is the first step to accomplishing what you want.

[Moose On The Loose]

An AppDir with many apps is the idea behind my AppPkg version of AppDir.
This would take going through each app and making it work in the AppDir.
Usually this isn`t too much trouble, some can be a real pickle at times.

What apps are in your SFS.? And it sounds like there`s some system files in it too.

Keep in mind my thoughts about apps and that there`s always a new one coming along.
So making the AppDir packages separately allows easy swapping out and merging of them.

A bare Puppy with utilities only, so it stays the same, while the apps are changed constantly.
.

Lets start with the browser. I want the "browse" button to work and clicking on an HTML file to work.

[Moose On The Loose]

Hey Moose; I`ve been trying to get a Chrome or Chromium AppPkg working.
It`s been such a mixed bag between web sites and SFS file problems.

# I`m hoping I can get a Chrome AppPkg uploaded to ally`s site.

# I made a Firefox-23 Virtual AppPkg here:
http://www.murga-linux.com/puppy/viewto ... 061#741061

# I`m wondering if you made a smaller SFS file with the apps that work.?
This is the first step to accomplishing what you want.

I have made a much much bigger SFS and the one under discussion. The bigger one is the Kicad and Ngspice one. I have it partly working but have the "ldconfig" issue I am still working out a good solution for.

[sunburnt]

Hey Moose; By browse button you mean desktop icon, or menu button?

Clicking is controlled by MIME, I`ve seen a mime editor in the Puppy menu.
But my current Puppy Percise-5.5.X.5 doesn`t have it. Should be a app. for it around... ASK.!

By the way, did you ever find the Default App. Chooser on you1re Puppy`s menu?
It sounded like that was one of the things you wanted to change also.
.

[MochiMoppel]

By browse button you mean desktop icon, or menu button.

I think he means the desktop "Browse" button, which calls /usr/local/bin/defaultbrowser.

The menu shouldn't be a problem because here the browser is called explicitely (mozilla in Precise, firefox in Slacko). If he adds another browser via SFS, then it would just add another menu entry.

Clicking on a html file in ROX eventually calls /usr/local/bin/defaulthtmlviewer, so both defaultbrowser and defaulthtmlviewer need to be changed.

[amigo]

It depends on what you mean by 'replace': If you want to permanently replace it, then it should be done as part of an installed package. If you want to temporarily make the original 'invisible' and have your modified version seen instead, then the only way is to use a union-mount so that your modified version gets seen instead of the original.

[MochiMoppel]

Sorry for quoting myself:

Can't you put your script into the SFS file? Either into /etc/profile.d or /root/startup? The script would reside on the SFS layer, so it would exist and run only when the SFS is loaded. Nothing to move, delete or check.

I made a small test with an SFS file. Creating /etc/profile.d and putting a script there doesn't work at all. Maybe SFS files are loaded after files in /etc/profile.d are processed...

The second option worked perfectly. I placed a script /root/Startup/changedefaults into the SFS file:

Code: Select all

#!/bin/sh
echo -e '#!/bin/bash\nleafpad "$@"' > /usr/local/bin/defaultbrowser
echo -e '#!/bin/bash\nleafpad "$@"' > /usr/local/bin/defaulthtmlviewer

Changes defaultbrowser and defaulthtmlviewer to leafpad, which admittedly isn't very useful, but sufficient for the test.. Clicking the Browse button or clicking on a HTML file calls leafpad.

The only problem I see: While the script would run only when the SFS file is loaded, the changes it makes to defaultbrowser and defaulthtmlviewer will be saved with the pupsave file. If this is acceptable, fine, if not, the script should be made more sophisticated and check for loaded SFS modules.

[Moose On The Loose]

[
The second option worked perfectly. I placed a script /root/Startup/changedefaults into the SFS file:

Code: Select all

#!/bin/sh
echo -e '#!/bin/bash\nleafpad "$@"' > /usr/local/bin/defaultbrowser
echo -e '#!/bin/bash\nleafpad "$@"' > /usr/local/bin/defaulthtmlviewer

Changes defaultbrowser and defaulthtmlviewer to leafpad, which admittedly isn't very useful, but sufficient for the test.. Clicking the Browse button or clicking on a HTML file calls leafpad.

The only problem I see: While the script would run only when the SFS file is loaded, the changes it makes to defaultbrowser and defaulthtmlviewer will be saved with the pupsave file. If this is acceptable, fine, if not, the script should be made more sophisticated and check for loaded SFS modules.

You are treading ground I have already covered. It is replacing defaultbrowser that I had tried by merely putting it into the SFS directly and was now thinking about as part of a script. The idea I've had so far is to do this:

The SFS has more than one script in it:

/etc/init.d/Script1:

Code: Select all

if test -e /etc/init.d/Script2 ; then
  exit
  fi
/someplace/Script3

/someplace/Script2:

Code: Select all

if test -e /etc/init.d/Script1 ; then
  exit
  fi
... put it all back to normal ....
rm /etc/init.d/Script2

/somplace/Script3

Code: Select all

cp /somplace/Script2   /etc/init.d/Script2
... make other changes ....

The purpose is to put in the changes if they haven't been and the SFS is newly loaded and to remove them if they have been if the SFS is no longer loaded. It could make for a very long script in real life but it is something I think I could automate.

[Moose On The Loose]

It depends on what you mean by 'replace': If you want to permanently replace it, then it should be done as part of an installed package. If you want to temporarily make the original 'invisible' and have your modified version seen instead, then the only way is to use a union-mount so that your modified version gets seen instead of the original.

This is what I had expected to happen when I had an SFS loaded at boot. What I really want is the layers to be like this:

The users save file: Anything in here wins over the other two
My improvements: Anything in here winds over the Standard stuff
Standard Stuff: You only see these if the above don't change it

It seems like I will have to code a script that does quite a bit of thinking to make this happen unless I can find some existing way to do it.

[MochiMoppel]

You are treading ground I have already covered.

Then why did you ask "Lets start with the browser. I want the "browse" button to work and clicking on an HTML file to work."?

It is replacing defaultbrowser

Yes, because this would solve your problem

that I had tried by merely putting it into the SFS directly

well, that THIS wouldn't work was clear from the beginning and discussed ad nauseam

[amigo]

The users save file:
My improvements:
Standard Stuff:

The way I see it, your improvements should simply go in the 'save file' -and should be delivered as an installable package. If you insist on using an SFS and having the whole thing be dynamically loaded/unloaded and to take priority over other installed files, then you need to use a more sophisticated approach.

If whatever system your puppy has for 'loading' sfs's during bootup doesn't do what you want, then you need to use a 'private' unionfs mount, plus possibly chroot-ing in there.

To me any system of loading/mounting these things which involves creating a bunch of links, backing up existing executables, and substituting them with new ones, etc.. are all madness. If you are gonna write files/links to the system anyway, just simply install the thing and be done with it.

There isn't really a one-size-fits-all solution for making software available dynamically -except for the most complex way above, with temporary union and chroot. This solution does provide a universal way to accomplish what you want and has the benefit of sandboxing the whole process.

Otherwise, there are simpler ways, but they only work for certain software. for instance, you can make a portable firefox/seamonkey which can be run from any location -provided all the needed libs are present- with the whole thing under a single directory. This is because the browser is started by a script which sets up all the dirs using environmental variables. Many very old programs for unix were also designed to run from the sources where they were built -that is, use a relative dir for the location of any referenced files.

If puppy had adhered to any sane usage of /usr/local (that is installing *nothing* there), then you'd be able to simply insert things under /usr/local and the natural PATHs of the system would make them have priority over anything installed under /usr.

Another way that works for some apps is to simply use a wrapper to start it, which sets the PATH and LD_LIBRARY_PATH to point to your prioritized libs and bins. But this generally only works for these two variables. Some applications accept and use other environmental vars, but rarely can one re-direct things like shared data or config dirs. That means that if your program looks for things under /usr/share, /etc or /usr/etc, you can't use a wrapper to redirect those -you need a union for that. Or you need to write a bunch of stuff into the users $HOME/.config, $HOME/.share or whatever -which is a really bad idea even if you make it work. And that only works if the program looks in those places first before looking in system locations.

[Moose On The Loose]

You are treading ground I have already covered.

Then why did you ask "Lets start with the browser. I want the "browse" button to work and clicking on an HTML file to work."?

I was hoping someone had a better answer. I have thought of quite along list of situations my scripts have to check for an take the right action based on. It is getting to be a fairly complex bit of logic to check for all the issues and it is far from a clean solution. If I miss a case, the method won't be generally workable and will instead have to be crafted for each case. This means making a script to make an SFS like this will be really hard.

It is replacing defaultbrowser

Yes, because this would solve your problem

that I had tried by merely putting it into the SFS directly

well, that THIS wouldn't work was clear from the beginning and discussed ad nauseam

Yes, there has been a lot of discussion but no clean solution.

[Moose On The Loose]

The users save file:
My improvements:
Standard Stuff:

The way I see it, your improvements should simply go in the 'save file' -and should be delivered as an installable package.

What started me down the path of making an SFS was the suggestion made over in the thread about Kicad that a large *.pet file was a bad idea. I am starting to think that perhaps the best path for the personal system is to do a remaster to make one SFS out of the whole system.

For things that I provide for others like Kicad, I think I will try to make something that works as an SFS. I don't expect to succeed but I do expect to learn a lot along the way.

If you insist on using an SFS and having the whole thing be dynamically loaded/unloaded and to take priority over other installed files, then you need to use a more sophisticated approach.

I may insist

If whatever system your puppy has for 'loading' sfs's during bootup doesn't do what you want, then you need to use a 'private' unionfs mount, plus possibly chroot-ing in there.

I need to read up on that idea, it may work but I can see an issue with doing it twice on the same system.

To me any system of loading/mounting these things which involves creating a bunch of links, backing up existing executables, and substituting them with new ones, etc.. are all madness. If you are gonna write files/links to the system anyway, just simply install the thing and be done with it.

On the Kicad, at least, I wanted to be able to swap out the version for a newer one later easily. Also since that is a pet file that weighs in at

Code: Select all

h-4.1# ls -l Kic*.1.sfs
-rwx------ 1 root root 207110144 2013-11-16 14:52 KicadNgspice-0.1.sfs
sh-4.1# 

It makes for a bigger *.pet than many people are comfortable with.

There isn't really a one-size-fits-all solution for making software available dynamically -except for the most complex way above, with temporary union and chroot. This solution does provide a universal way to accomplish what you want and has the benefit of sandboxing the whole process.

Yes, I think this is the best idea so I will spend a little time reading up on it next time I have the free time to work on it.

--- snip ---

If puppy had adhered to any sane usage of /usr/local (that is installing *nothing* there), then you'd be able to simply insert things under /usr/local and the natural PATHs of the system would make them have priority over anything installed under /usr.

Another way that works for some apps is to simply use a wrapper to start it, which sets the PATH and LD_LIBRARY_PATH to point to your prioritized libs and bins. But this generally only works for these two variables. Some applications accept and use other environmental vars, but rarely can one re-direct things like shared data or config dirs. That means that if your program looks for things under /usr/share, /etc or /usr/etc, you can't use a wrapper to redirect those -you need a union for that. Or you need to write a bunch of stuff into the users $HOME/.config, $HOME/.share or whatever -which is a really bad idea even if you make it work. And that only works if the program looks in those places first before looking in system locations.

Yes, the union method does seem the only clean method available that will work in all cases. For my own purposes, a remastered SFS will work. For stuff I want to share. I either need to give up on making it general or go with your suggestion.

[sunburnt]

You should expect to succeed Moose.

Using chroot is one of the few ways to make a no-install app. I`ve done a few.
Compiling in several different ways can make one also. Did you compile Kicad.???
Firefox that koulaxizis made is completely portable to anywhere.

So it finally sounds like Kicad is the real problem.
By any chance have you identified the problem files in Kicad.? Possible fix here.

Did you ever make a new SFS file without Kicad ( and any other apps. that don`t work ).?
Or maybe Kicad is the SFS file`s purpose. Separate Kicad so it can be upgraded easily.

If Puppy added new SFS layers underneath the Save file and not at the bottom...
This obviously can cause a sys. crash if a bad SFS file is added ( Barry`s thought I`m sure ).
.

[Moose On The Loose]

--- snip ----

Did you ever make a new SFS file without Kicad ( and any other apps. that don`t work ).?
Or maybe Kicad is the SFS file`s purpose. Separate Kicad so it can be upgraded easily.

The Kicad SFS is one that brings in the whole Kicad collection of programs and also ngspice. It doesn't have to have any changes to existing files to work but there were a few things I was planning on doing. The main thing I was working on on that project was the issue of ldconfig not existing on some machines but being needed to make the libraries work. It works nicely as it is, so long as the user doesn't mind having to manually run the ldconfig.

If Puppy added new SFS layers underneath the Save file and not at the bottom...
This obviously can cause a sys. crash if a bad SFS file is added ( Barry`s thought I`m sure ).
.

As it is, an SFS that adds something very bogus at the /etc/init.d level can make a system that is really messed up.

I may look into the order of layers thing. Maybe the fix is to roll out a kit that makes the loaded SFS appear above the default one. Perhaps a different extension can signal that it is one of those.

[sunburnt]

The SFS file builder can make sure his SFS file doesn`t cause system conflicts.
But the SFS builder cannot possibly account for all the SFS files that may be used.
The over-shadowing of union layers is just a failing reality of union FSs.

The only fix is "custom tuning" of any conflicting files between the SFS files ( not acceptable...).

Independent portable no-install apps don`t have this problem of course ( why I keep at them...).

Suggestion: Instead of using ldconfig, use a wrapper script with:
LD_LIBRARY_PATH=$YourLibPath:$LD_LIBRARY_PATH

# This doesn`t add extra Lib. Paths to the main LibPath, only to the LibPath in your app.
.