yes what a dumb distro...why not just copy how slax layers then the problem disappears...The reality is that it solves the union shadowing problems that Puppy has always had.
mike
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.sunburnt wrote: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 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.MochiMoppel wrote: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.Moose On The Loose wrote: 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.
Lets start with the browser. I want the "browse" button to work and clicking on an HTML file to work.sunburnt wrote: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.
.
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 wrote: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 think he means the desktop "Browse" button, which calls /usr/local/bin/defaultbrowser.sunburnt wrote:By browse button you mean desktop icon, or menu button.
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...MochiMoppel wrote: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.
Code: Select all
#!/bin/sh
echo -e '#!/bin/bash\nleafpad "$@"' > /usr/local/bin/defaultbrowser
echo -e '#!/bin/bash\nleafpad "$@"' > /usr/local/bin/defaulthtmlviewer
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 second option worked perfectly. I placed a script /root/Startup/changedefaults into the SFS file: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.Code: Select all
#!/bin/sh echo -e '#!/bin/bash\nleafpad "$@"' > /usr/local/bin/defaultbrowser echo -e '#!/bin/bash\nleafpad "$@"' > /usr/local/bin/defaulthtmlviewer
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.
Code: Select all
if test -e /etc/init.d/Script2 ; then
exit
fi
/someplace/Script3
Code: Select all
if test -e /etc/init.d/Script1 ; then
exit
fi
... put it all back to normal ....
rm /etc/init.d/Script2
Code: Select all
cp /somplace/Script2 /etc/init.d/Script2
... make other changes ....
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:amigo wrote: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.
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."?Moose On The Loose wrote: You are treading ground I have already covered.
Yes, because this would solve your problemIt is replacing defaultbrowser
well, that THIS wouldn't work was clear from the beginning and discussed ad nauseamthat I had tried by merely putting it into the SFS directly
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.The users save file:
My improvements:
Standard Stuff:
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.MochiMoppel wrote: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."?Moose On The Loose wrote: You are treading ground I have already covered.
Yes, there has been a lot of discussion but no clean solution.Yes, because this would solve your problemIt is replacing defaultbrowserwell, that THIS wouldn't work was clear from the beginning and discussed ad nauseamthat I had tried by merely putting it into the SFS directly
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.amigo wrote:The way I see it, your improvements should simply go in the 'save file' -and should be delivered as an installable package.The users save file:
My improvements:
Standard Stuff:
I may insistIf 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 need to read up on that idea, it may work but I can see an issue with doing it twice on the same system.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.
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 atTo 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.
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#
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.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, 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.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.
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.sunburnt wrote: --- 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.
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.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 ).
.