Removed built-in applications still show in package manager

[Makarovnik]

Running bionicpup64. When I use the menu item to "remove built in applications" they appear to be gone but still show up the puppy package manager as "already installed". Even.after purging their directories from ~/. config and ~/.local. Any way to tell the puppy package manager they have been completed uninstalled. I have my reasons for doing this. One would be for a clean remaster.

[mikeslr]

For some unknown reason /root/.packages &/or the files in /root/.packages/builtin_files is not being updated. Note the "."/dot. It's a hidden file. Left-Click Rox's "Eye" or otherwise have your file-manager "Show hidden files". If you're sure they're gone, you can delete the file references to them. AFAIK, the use of /root/.packages is Puppy-specific.

Some newer Puppies now also apply the generally used system of storing references in /var. I don't know why as I don't think Puppy makes any use of that information by the 'remove_builtins' routine or otherwise.

[bigpup]

/root/.packages &/or the files in /root/.packages/builtin_files do not get changed.
That is not how remove built in applications works.

remove built in applications does not actually remove anything.
Because the files and programs are in the main sfs (that is read only), they get white listed.
Anything white listed will not show up as active in the file system.

Do not worry about what PPM shows.

The process of remastering is suppose to bypass anything that is white listed and not make it part of the new remaster.
So use remove built in applications and those items removed will not be in the remaster.

Be very careful what you do with remove built in applications.
Strongly suggest only remove a program that is in the main menu of programs.
But you need to be careful it is not a program that may be used by some other program.

Single item files listed in remove built in applications.
Removing them usually will break something!!!!

[user1111]

A smaller main sfs is only desirable when you are loading/running everything from ram. For that perhaps using woofCE to woof your own configuration is more preferable over that of looking to remaster to downsize. Woof is relatively simple to use, but is quite time consuming (more of a run overnight type task, and where when unfamiliar you may end up having to do multiple runs (subsequent runs do tend to be quicker however due to already having downloaded the relevant files/data)).

A factor to consider is that running in ram uses more ram than not running in ram. If for instance the main sfs is 500MB and averages 50% compression, then if all data blocks are at some point read during a session then that might eat around 1.5GB of total ram .. the 500MB of (compressed) sfs content, and the 1GB of non compressed data that had been cached.

A alternative is to run without copying the sfs into ram. When the sfs is compressed using a fast decompression method such as lz4 that can actually be quicker to read/load than direct non compressed loading. Read half as much from disk and decompress it to twice that size ... compared to reading twice as much 'ready to go' (non compressed) data from disk. That way you'll find that it uses less total ram than what running-in-ram uses, leaving more ram available for other things. Yes the first time a program is run it will have more of a lag to start compared to if already loaded into ram (where it just has to be decompressed into cache), but subsequently more often there's no difference in program launch speed as both methods have the program already cached.

I use Fatdog, and my 'remastered' main sfs for that (fd64.sfs) contains around 2.5GB of non compressed sized content, that is around 1GB when compressed using lz4 (mksquashfs squashfs-root fd64.sfs -comp lz4). Without that being loaded into ram after bootup it uses around 250MB of ram space whilst operational (and boot) speeds are more than acceptably 'quick-enough'. In that context size doesn't matter. Much of that content likely never gets read/used during a single session, is redundant, but in other sessions those prior unused elements might be called upon/used. Such as gparted that is quite a large binary filesize, is infrequently used, but handy to have it ready to go when needed.