Keeping track of what's in adrv, ydrv etc.
Posted: Thu Oct 29, 2020 3:53 pm
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).
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).