PPM installs directly to SAVE_LAYER?

[gyrog]

Does the current PPM try to install directly to the SAVE_LAYER?

I hope someone is significantly familiar with PPM to answer this question without digging into it. (Otherwise I will have to do the digging myself.)

In my investigations with "overlayfs" I have overlooked this question. But it's important because directly modifying a directory that is part of an "overlayfs" stack is unsupported. Also whiteout files in "overlayfs" are not the same as whiteout files in "aufs".

Unfortunately, if the answer is "yes", I'll have to patch PPM.

[bigpup1]

I am not sure you can judge how Puppy does overlayfs against the normal way it is done. Puppy does a lot of stuff the Puppy way.

What is the problem? PPM seems to be working no matter what pupmode puppy is operating in.

Depends on the pupmode Puppy is running in.

In pupmode 12, usually used when Puppy is installed to a hard drive. The save is mounted read/write all the time. Any new changes that go into the save are written as they happen. Installing a package from PPM would go directly into the save at the time it is installed.

In pupmode 13, usually used when Puppy is installed to a USB flash drive. The save is mounted read only, but ther e is a saveramdisk in memory that is used with it. The saveramdisk gets all the writes to the save until you click on the save icon on the desktop, the write to save set time interval activates, or you do a shutdown.

Puppy installed to a CD/DVD is using a saveramdisk most of the time. It runs in pupmode 5. So, writes to save are as they happen. If you make a save on a, say hard drive, to be used with the Puppy CD/DVD. The save on the hard drive will be mounted read/write all the time. So writes to this save are as they happen. It is now in pupmode 12 operation.

A CD/DVD Puppy install can also be in pupmode 77. The save is written to the CD/DVD. At boot the save on the CD/DVD is loaded along with the rest of Puppy. It uses a saveramdisk mounted read/write and writes the contents of this onto the CD/DVD at shutdown.

So the answer is yes. It writes to the save as it happens. But the save could be a saveramdisk or the actual save file or folder. I am not sure how the saveramdisk is layered into the file system.

This info may help you. How Puppy works: http://bkhome.org/archive/puppylinux/development/howpuppyworks.html

[mavrothal]

If I remember correctly in PUPMODE 3, 7, 13 have the configuration option to install either at tmpfs (default) or in /initrd${SAVE_LAYER}. In other modes packages are installed at root (/) though mode 2 is a bit different as there is a step to ensure that you save existing files before clobbering with the new package. Check installpkg.sh and look for "DIRECTSAVEPATH" for the relevant code.

[gyrog]

Thanks for the responses, I think the answer is 'yes'.

Though in a strange way, it matters "how it is written" more than "where it is written". From a quick look at installpkg.sh, if it uses "DIRECTSAVEPATH" then that is direct access to the directory, not via the stack's mount point and hence unsupported in an "overlayfs" stack. And of course it mucks around with whiteout files, "aufs" based code will never work with "overlayfs" whiteout files.

So I'm going to have to patch PPM to never use "DIRECTSAVEPATH" and never muck around with whiteout files.

Hmmm... current pupmode=2 could be close to what I need.

[wdlkmpx]

Maybe sc0ttman's PKG should become the new ppm and patches and fixes should be applied to it.

I haven't tested thoroughly but they say it works in cli and gui mode

[mavrothal]

PKG is good for what it does which is almost everything! However, it provides a lot of opportunities to break your system if you do not know what you are doing. So it will need at least a standard mode and an advanced mode. Though the major problem with PPM I think is the (mixed-bug) packages and the repos, and PKG inherits all of that. So I would say include it as an additional manager in a couple of "official" releases (whenever they come) to have some extended testing first because by now it has very little and only from "adventurous" users

[wdlkmpx]

Well PKG could lead to a different type of evolution in puppy, but in puppy in general there are too many things to do to make it better.

PKG should be included directly in rootfs-skeleton as an alternative core app to ppm. That way it's easier to identify issues.. i don't know what sc0ttman thinks. i don't think i will be testing it heavily but there are many people who will (theoretically).

Gyro should also be including his stuff in rootfs-skeleton and initrd, as long as it's not the default behavior, it can be tested and refined by everyone building isos..... here be dragons. Unification will take forever, since it requires someone who understands the whole thing and unifies all apps..

[gyrog]

FYI: I've done some testing of PPM, simply forcing "installpkg.sh" and "removepreview.sh" to use pupode=2, [ "$PUNIONFS" = "overlay" ] && PUPMODE=2 where as I'm actually running in pupmode=12. It works fine. ( I do end up with an "/audit" directory, but that's easy to ignore.)

One of the problems with PPM is this "hairy" idea of "fooling" the stack and writing directly to the SAVE_LAYER, it's not worth all the hassle. And if we ever have to abandon aufs we will probably have to abandon it then.

[wdlkmpx]

PPM saves directly to save_layer only in PUPMODE 13, because the real "personal storage" is RAM.

So back in the day, ram was very important, i think it still is, many puppy users are used to use very low end hardware (1GB) even when they get newer hardware.

Using ubuntu/debian or even slackware ensures package installations can get a little big. It's not hard to create a very small puppy with small packages where only size matters, using one of the very lightweight distros as compat distros. Currently rootfs-skeleton is not very friendly to some busybox applets, but it can be fixed. One ubuntu puppy for daily and generic use and one tiny puppy for amusement. Sounds like a good idea.

[gyrog]

RAM issues can often be allievated with a significant size swap partition. Yes, the install will be slow, but in odd pupmodes it will be copied to the save-layer at shutdown. So the slowness should only effect the current sessioin.