Maybe the 'foreign' portion of the PPM could be nothing more than an sfs - so that it allows the foreign package to be run in a nondestructive way, then discarded at next boot if unsuccessful. Sort of like a "static_package_on_the_fly"

Things other than sfs and {2,3,4}fs files can be unioned. For instance you could install all Debian Wheezy packages to /mnt/sda1/wheezy and union it to / ... likewise for any variant of any distro._________________Web Programming - Pet Packaging 100 & 101

For instance you could install all Debian Wheezy packages to /mnt/sda1/wheezy and union it to / ... likewise for any variant of any distro.

If that process was used - how easy would it be to "un-union" or unload or disconnect those packages if they started to show an undesirable effect and the user wanted to get rid of them? I was thinking that an sfs was easier to disconnect (unload) but is an sfs really no different to the unioning you have described?

An SFS is a file system image. You can make a file system image using any file system you like. Any of them can be used any of the ways normal file systems are used -including adding them to a union mount -either as read-only or as read-write if the file system permits that(SFS, cramfs, and cromfs do not).

An SFS is a file system image. You can make a file system image using any file system you like. Any of them can be used any of the ways normal file systems are used -including adding them to a union mount -either as read-only or as read-write if the file system permits that(SFS, cramfs, and cromfs do not).

For file systems that are read only, having a writable layer above them makes it look to the user like a write can be done. Making a utility that can make a new SFS from the old with the changes can be added as a "rebootish" option so that the user can do it on demand.

I want everyone to understand that I am NOT a Linux distro/application developer. But, over the years, I have heard and understand rationales presented for compressed filesystems as well as use of SFSs as well as unioning and other ideas and implementations.

One of the things that is constantly thrown onto the table is the notion of install packages "trashing" a running system.

Here's my problem
Excepting for the often times when a newer distro is released and where a user tries to use/install the new distro to the PC using the old distro's older save-file(s), I have not witnessed any general user complaints of installing package(s) that locks or crashes their Puppy distro system.

Questions

Even though its a conceivable occurrence, are package installation crashes happening?

And if so, at what scale?

Does the current package system really need a re-architecture?

Should or will any new approach be simple for new and experienced users to extend PUPPY with subsystems and application should a user desire?

Curious_________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engineor use DogPile

Sure.
Don't bundle stuff together.
Get dependencies straight.
Package each binary and library separately.
Separate architecture independent resources.
The package manager should warn if an uninstall will affect other packages.

Debian, for one, has strict rules about this.
Puppy, on the other hand has played fast and loose.

Side note: Puppy went about half a decade without a proper uninstaller. It took <10min for me to write one in ~10 lines including reverse dependency checks (I actually wrote it as a 1-liner at first). The current method is bad for multiuser though since installed packages go to /root/.packages/... instead of /var/..._________________Web Programming - Pet Packaging 100 & 101