Hi again amigo; This is my experience, it works great, take it next door to show my friend and it bombs.
Need standardized "known" base for the O.S. so everyone is on the same page. No more assumptions...
Apple has it much easier than M$, Apple`s hardware is known and fixed, M$ has to support everything.
I`ll try your update when I shut off this running AppPkg of Chrome. Tests when it`s on does odd things.
A GUI tool will have to be fairly simple. Developing AppPkg will produce many AppPkgs to host for users.
So far I`ve downloaded pkgs. manually, a GUI interfaces this part of AppPkg building, and build choices.
The background code resolves deps. and downloads them, assembles the AppPkg, and makes scripts.
There is always odd stuff to fix, some of it can be automated, some of it will always be manual labor.
Any tools for working with AppPkgs would also be AppPkgs of course.
A link: /opt/AppPkg => /mnt/(partition)/AppPkg gives a reliable path to AppPkg apps. and any tools.
If src2pkg will download binary app. packages and gets their deps., then no need to parse web pages.
I assume it will do this for Debian, Slackware, etc.? So then AppPkg would have a bigger base of O.S.s.
I have already made a GUI in BaCon like the Debian packages page. An App-Groups list and Apps. list.
A second tab shows the description for the selected app. A third tab is build control, options, and paths.
For AppPkgs that have more than one app., I wrote a popup menu in BaCon, it uses a std. menu format.
This is part of the menu file for my AppPkg of the Xfe and Fox suites of apps. ( Name Desc.:Exec.:Icon ).
Code: Select all
Xfe File Manager:xfe:xfe
Xfi Image Viewer:xfi:xfi
Xfp Package Manager:xfp:xfp
Xfv Text Viewer:xfv:xfv
Xfw Text Editor:xfw:xfw
When you click on Xfe_Fox.AppPkg or run AppRun it pops up the AppPkg menu to select from. ( See pic.)
It was a nice experiment as it shares the FOX libraries in a /lib Sq. separate from the app`s. Sq. files.
It`s infuriating because in this AppPkg LD_LIBRARY_PATH works just fine ( it works, then it doesn`t...).
This is the extra /lib dir. I spoke of, not system wide, but shared in an AppPkg with >1 app. needing it.
End-users can also use this same /lib dir. to easily patch the AppPkg with any libs. their O.S. is missing.
When I say SFS I mean a Sq. file made for Puppy that`s to be unioned. Some SFS will work non-union.
A Sq. file`s a normal Squash file of any kind, can be a Bash tutorial, install app., union image, anything.
AppPkg can use Sq. files or the mount dir. can just contain the app`s. files ( Good to develop the app.).
I thought of using the original app. files r-w, but this allows corruption, best to use the app`s. files r-o.
Hummm... Use an iso image, interesting idea amigo, Sq. files use a kernel module, does an iso file too?
Versions: Most apps. I`ve seen create dirs. in $Home and /usr/share, and these dirs. aren`t versioned.
If the apps. could be made to put versions on their dirs. that`d be nice. If we could only configure apps...
Like modifying the paths within binary exec. files, some apps. will work and all too many of them won`t.
Lib. stats would be useful for building an O.S. ( what to put in it...). It could also help in making apps. too.
### A couple of Qs I`ve been meaning to ask:
# Do all libs. load to ram? So lib. "file" is read once? So can unmount a lib. Sq. file after app. startup?
# Is a mount dir. on a partition slower than one in ram ( say: /tmp )? Like a link, it must be resolved.
....... So to access a link or mount point that`s on a HD, USB, or CD the device is accessed continually?
....... Web page clicks cause the HD light to flash. The /etc/resolv file should be in /tmp. Bad O.S. design.
### Again many thanks for hanging in there on this amigo. Now I think it`ll become a reality.! Terry B.
.