Keeping track of what's in adrv, ydrv etc.

[mikeslr]

Hi All,

I don't have any idea about a programming solution. Perhaps its not really a problem. But thought I'd mention it.

[The inclusion of pkg-cli may have changed this somewhat, but] Packages included in a Puppy as published are noted in /root/.packages/builtin_files. Menu>Setup>Remove Builtin Packages will [as I understand it] 'white-out' or alter the inode relating to that 'Removed' applications such that their files are no longer seen as part of the system, AND remove the relevant notation in /root/.packages/builtin_files.
As a user installs applications (into the SaveFile/Folder) such packages are noted in /root/.packages. Puppy Package Manager >Uninstall will physically remove files, 'white-out' or alter inodes relating to them; and remove the relevant notation in /root/.packages.

If you remaster a Puppy, previously 'removed built-ins' are neither included nor referenced in /.packages while applications which had been installed into a SaveFile/Folder are then noted in /.packages as builtins. But what if --instead of remastering-- the SaveFile/Folder is converted to an adrv.sfs (or other 'alphabet.sfs)? There are, at least, three ways to effect that conversion that I know of: (1) manually copy SaveFile/Folder into a folder named --for example-- adrv, then dir2sfs that folder; (b) include the SaveFile as a source to be used by PaDS, having where appropriate converted a SaveFolder to a SaveFile; and (c) using the module under nicOS-Utility-Suite which converts a SaveFile/Folder to either an adrv.sfs or a ydrv.sfs. I think I used the latter which resulted in this condition:

Applications now in the adrv.sfs still had related files noting their existence as user installs in /root/.packages and Puppy Package Manager continued to show them as "installed". But an adrv.sfs is a READ-ONLY file system. Uninstall can't actually uninstall the application. [Perhaps "uninstall" --like Remove Builtin Packages-- can 'white-out' or alter the inode relating to that 'Uninstalled' applications such that their files are no longer seen as part of the system, and remove the relevant notation in /root/.packages. But I'm not even sure of that]. I haven't done any testing. I only discovered the condition when, experiencing a problem, I wondered what I had recently installed that might have caused it and examined Puppy Package Manager's Uninstalled read-out.

I was able to figure out which applications listed by Uninstall were ‘post-adrv-conversion’ as I had taken a screenshot of what was installed prior to the conversion.

Perhaps PPM's misidentification is not a problem, only an annoyance. Converting a SaveFile to an adrv seemed like a good idea at the time. But the above adds to my growing suspicion that ‘alphabet’ SFSes are best employed for applications you can include and never have to think about again such as zdrv (drivers and firmware) and fdrv (firmware).

[williams2]

I usually boot Puppy using pfix=ram, and using the stock standard compressed and read-only puppy.sfs
Puppy creates a layered file system with the read only sfs file systems on the bottom and a read/write layer on the top.
Without a savefile, and pfix=ram means to not use a savefile, the top writable layer will be a tmpfs file system that is in ram memory.

Normally, Puppy would use a savefile on a hard drive or usb drive as the top writable layer. Any changes you make would be written to the savefile and would be there the next time you boot.

Puppy has for a long time had scripts allowing you to modify the original Puppy sfs file, to make a new puppy.sfs file that incorperates the changes you have made in the new puppy.sfs file. You can change the wallpaper, add and delete icons on the desktop pinboard, set up your network and internet connections, add and delete programs, etc, etc.

If you boot that remastered Puppy with the remastered puupy.sfs file, without a savefile (pfix=ram), then all the changes you made, to the pinboard, to your network and internet, etc, etc, will still be there, in the remastered puppy.sfs file.

You can do almost the same thing, without modifying the original puppy.sfs file, by creating an adrv.sfs file with your changes that are in the top writable layer of the file system. One difference: if you delete a file or dir that is in an sfs file, it can't really delete the file in the read only sfs file, it can only write to the top layer. So it puts a whiteout file in the top layer. The file seems to be deleted.

If you create an adrv.sfs file from the writable top layer, files and dirs that were added will be added to the adrv.sfs file, and will work properly. If whiteout files are copied to the adrv.sfs, they will be invisible, but aufs will ignore them, the will not do anything, the files that were "deleted" by the whiteout file will no longer be deleted, it will be visible in the file system again.

If you try copying the whiteout files from the adrv.sfs layer to the top writable layer, aufs, which creates the layered file system, does not like it at all.

What you can do, if you want certain files to be deleted, is to run a script when Puppy boots, to delete files that you want deleted, that are in the sfs files. For example, there might be a dir /root/firstrun/ that is deleted the first time Puppy boots. If you convert your savefile to an adrv.sfs, whiteout files in the adrv.sfs do not work, and that dir will no longer be deleted, and will be visible again.
An adrv.sfs can add or modify files, but it can not delete files that are in the sfs layers.

There is a thread or threads on the Murga forum that discuss this. I think there was a script posted that would delete files that had corresponding whiteout files in the adrv.sfs.

Aufs has options that Puppy does not use. For example, you can configure it to write certain files to certain layers. Puppy is not using all of these options. Basically, Puppy makes a stack of read only sfs's with a writable layer on top.

So this is a limitation to using adrv.sfs files. If you actually remaster (modify) the original puppy.sfs file, you can actually delete files in the original puppy.sfs, as opposed to whiting them out.

[dancytron]

That's an excellent explanation.

It should be a sticky somewhere.

[puddlemoon]

Interesting indeed

I have had a similar conundrum recently, kinda...

In the process of refining a remaster of fossapup for my audio project, which at some point it became clear that I would share, so I had to decide what to do with /var/packages...

I had combined the adrv and the main puppy.sfs which didn't really matter (except perhaps to confuse me a little extra) as they both have only builtin packages.
I had installed a couple dozen or so packages, mostly from a non-standard repo accessed through pkg.
I knew that I did not want them to clutter up and confuse the uninstall list in the ppm, even though the newest is last on the list, it seemed just too... messy.
But I certainly wanted to include them somehow.

So after some trial and error(s) and head scratchy reboots, I ended up with this simlpe workaround,
I moved all the .files files in /var/packages to builtin_files_norm.
It seems the builtin_files folder is a combination of builtin_small and builtin_norm, adding the files to builtin_files did not stay.

I also moved /var/packages/user-installed-packages to /var/packages/layers-installed-packages, however this was overwritten in the end...
I didn't try adding them to "woof_installed_norm" as that seemed a bit cheeky..

With the .files in builtin_files_norm I am able to see all the added packages in the "remove builtin packages" dialog and they are not present in the uninstall dialog.
The packages I added through the kxstudio repos via pkg are shown correctly as installed in pkg. Also the packages added from main repos seem to be shown correctly as "already installed" in ppm.

Anyway, a bit of a rough hack on my part but it did, for the most part, do the job for me... Maybe a quick edit of /var/packages could help make the new adrv be less confusing?

Side note: I also made a ydrv of a few of the larger apps I wanted to make available by using apt2sfs in fossadog then removing any conflicting files... this works well but no reference at all for the package managers in puppy, so they are kinda phantom apps...