Package uninstall management

With Quirky 6.0.1 I laid the foundation stone of my planned "audit trail", to properly manage upgrading/downgrading/recovery.

Now, I have taken the next step, some bricks mortared in to properly handle package uninstallation.

Mavrothal recently experienced a problem with Quirky 6.0, when he uninstalled a PET package that has critical Xorg files in it, like /usr/bin/Xorg for example.
The problem is, this is a "full installation", there are no layers. With frugal-installed puppies, there is a bottom puppy.sfs layer, that is read-only, the files can't be removed, and uninstalling a PET one-layer up will just expose the files underneath -- so the original /usr/bin/Xorg will be exposed.

But, as mavrothal experienced, when the PET was uninstalled, there was no longer any Xorg, etc. And, I recall, mavrothal used the word "hosed" to describe his Quirky installation.

I have now implemented a solution, and it goes far beyond the underneath-layer recovery of Puppy.

I have modified two files, /usr/local/petget/installpkg.sh and removepreview.sh -- not in Woof, I am maintaining all of these changes separately and applying them afterward.

When a package is about to be installed, any files that it replaces get saved. Let's say that I am going to install 'xorg-server-1.15-x86'. Just before the files get installed, any files that are going to be overwritten get saved, into /audit/xorg-server-1.15-x86DEPOSED.sfs.

This process happens to all packages. so we could end up with a lot of those "DEPOSED" SFSs. That is good. The removepreview.sh script is now very clever, and when a package is uninstalled, it determines the latest required deposed files that need to be restored.

For example, if I uninstall xorg-server-1.15-x86, but perhaps I had installed lots of other packages after I had installed xorg-server-1.15-x86. The uninstall script looks to see if any later-installed packages have overwritten any of the files of xorg-server-1.15-x86, and the most appropriate files get restored.
The script also considers the dependencies of packages, and will refuse to uninstall a package if a later one has it marked as a dependency.

The great thing about this, is you could have, for example, installed a couple of dozen packages, then you can uninstall one right back at the beginning, and nothing will be broken. That's saying something. Well, I think it will work, the logic seems ok, but haven't done any heavy testing yet.

I am aiming for Quirky to be update-able indefinitely, and old stuff pulled out as desired, without breaking things.

Next step
I intend to apply this "deposed" mechanism to the 'new2dir' script, so that developers who are compiling apps for Quirky will also have this rollback feature. new2dir can also register a newly compiled and installed package with the Package Manager, to enable one-click uninstallation.

---

Comments

The 'new2dir' script calls the 'installwatch' utility to record all installed files. I had thought of modifying installwatch.c to grab files before they get overwritten, but that is too difficult to figure out.

Note, there are many different versions of installwatch source on the Internet. It is actually part of the 'checkinstall' package, and the latest installwatch is 0.7.0beta7, available here:
https://github.com/ruxkor/checkinstall/tree/master/installwatch

...go one-up and there is a button to download a zip of the source.

So, I might do it a different way. Take a snapshot of the complete system, create delta file relative to the previous .usfs or delta file, so hopefully it won't be too big.
That will enable roll-back if the compiling goes wrong, or you just want to get rid of what you compiled/installed.

Though, there is no need to keep the snapshot, it can just be used to determine what files have been overwritten, to create a "deposed" sfs file.

Testing what will become Q6.1, I can take a snapshot of the system, then install the "devx" PET, then if I recover the snapshot, the system get restored seemingly perfectly, just as though the devx PET was never there. So, that is one thing that works real nice.

Note, Q is no longer using SFS files, the devx and kernel-source are now PETs.

The devx PET is very invasive, and the problem I am working on now is to get the Package Manager to uninstall it.
There are some critical files, that when deleted cause the uninstall process to crash the system.

I have written about the "deposed" mechanism, so that files that got overwritten when the devx PET got installed, are put back in when the PET is uninstalled.
However, this is not atomic, the uninstall script first deletes the devx files, then copies in the "deposed" files. So, there is a gap in time when those files do not exist, and the script fails to get to the part where it is supposed to bring back the "deposed" files.

To fix this, I am compiling busybox statically, and will run the uninstall script using the applets of a copy of that busybox, so the script will not fail.

Tags: linux