The idea I had was to let the script use attributes, that is,
when Haiku boots without issues, the script would add the attribute Boot/OK, and Default/OK
- when user pins a state would add attribute Pinned/YES
- when user unpins a state would remove attribute Pinned
- when user removes a state, first checks if it’s pinned or the last with Boot/OK in which case, you know… warn the user
- when user clears the states, removes states without Pinned/YES and the last ones with Boot/OK
- when user lists states, these attributes would appear there too
- and when user sets default boot, would set Default/OK to the new one, move it to the right place and remove attribute Default/OK from the “old one” and move this to a storage folder.
Well, that was the idea until I found out that states are just text files with a list of active packages. In my case, on nightlies, and testing software, installing, uninstalling… lists are quite large and vary a lot from state to state, even same day. So I presume that this approach does not make much sense as I could just delete old states from the hard drive and done, no need to worry about managing anything.
Then, if it were actually snapshots or “system deployments”, I am quite sure devs would have already implemented the tool to manage snapshots with their rollbacks.
Nonetheless, digging into the attributes thing was very interesting and hope I’ll be using that sooner than later.