Settings to automatically erase previous system states

If I don’t use a program in 30 days I don’t like the settings to be removed. A clean up can be handy where you can choose to set the date by your self.

One thing I do misses are when I uninstall a program with HaikuDepot I don’t think it will remove my other dependency packages and not the setting for it? That would be nice :slight_smile:

3 Likes

To be clear this is about cleaning system states (snapshots), not about program settings being reset.

1 Like

I do not like things to happen automaticaly…
You updade manual and therefore deinstall manual is ok!

The HAIKU way should be like it is now!
If the user do nothing, nothing will happen!

I do not like the OS is going to do something without my knowledge!

You can manually inform the user to manually delete old files if necessary on the forum or Homepage or the Calendar!

I hate auto delete or install!

I don’t think this is needed for the brta releases, but for nightly it might be nice.

I would like to add that 10 (or 3 in the example on top) states is way too low a number, just browsing through haikudepot and installing some games will quickly get you over that number. Most states are just text files for the set of software anyway (and in some cases reinstalling old software picks them from previous states too)

Personally i wouldn’t use such a feature, but i think a number of 300 states or so could work, but perhaps a disk size limit is the best option indeed.

It goes about the administrative files right?

https://old.besly.de/menu/search/archiv/pref/avoid-longer-boot-times_eng.html

Humdinger and myself creates a bootscript to manage this files in the past. I does not know if it is running anymore, because i does not use it, but can be an idea and start up for future handling.

Nice script @lelldorin, maybe an option to “move” the files somewhere else instead of deleting them directly would be better, if on a reboot problems arise one would still have an option to restore them?

But that wouldn’t solve the issue of disk space that removing old system states would. I’m fine with the option of moving them somewhere else, but not outright using that in lieu of deletion.

At times I have quite a lot of “states” due to building/installing/uninstalling, and once in a while I move the old states to another place, after some reboots and things are still ok I remove them (ps, disk space is not really a problem here)

If that’s to a different disk, sure. But it doesn’t really work if they’re just being moved to another place on the same disk.

Didn’t know that one (should check it out at some point), so you mean like if I move them to “~/backup” the states are still being seen?

No, but they’re still taking up disk space.

Ah, thought so :slight_smile:

Just checked, 155 states in there (and first one from April 25) :wink:
EDIT and taking up 1.19 GiB :open_mouth: :wink:

I can make a little gui for managing

My hope would be the way I implement this will be useful for most people. The cleanup functionality will of course be written in C++ in the Package Kit and besides the automatic setting it could also be run manually maybe with pkgman cleanup or a similar name. That could either use the current (or default) settings which are exposed in a GUI preference somewhere, or they could be passed on the command-line to override those settings. There could also be a menu or button in HaikuDepot, or in whatever app since ideally this is just exposed as a Package Kit API.

I feel like that will give maximum flexibility and there will hopefully not be a need for outside utilities for this. Plus of course whoever wants to keep all their states can just never turn this on. But I feel this is something that should be handled by the operating system.

Maybe another aspect would be consolidating state directories (making many states into one), but to be honest I need to spend more time learning how those state directories work for both cleanup and consolidation.

With all this said it is also very important I actually work on it and not just talk about it :rofl:

10 Likes

Perhaps a setting saying keep last 3 version or so, with that option I don’t mind it being automatically.

Good day,

Check out this (wrong approach, dismiss)'haistate' command line tool to manage system states (proof of concept)

This was a wrong approach because I thought that Haiku’s states were somewhat like snapshots, so we could get rid of old snapshots not in use. Actually states, if I understood @PulkoMandy correctly are just plain text files that keep a “diff” of packages compared to the prior state. I was thinking about the Fedora Silverblue deployment approach, but that does not apply here at all. In fact, I was doing some Python tool to manage that, but stopped due to the wrong approach taken.

Not sure if it makes sense, but it could be an idea to have a tool, be it command line, be it gui, that updates the state to “merge” all diff state files into an actual state that has proven stable with all packages that are active at the moment thus creating a “new complete state” that has no prior dependencies. That new state could be saved by the user as “non deletable” until the user decides to move forward. Also, that new state could be the base for further diff states? Just thinking aloud.

Regards,
RR

The states are made of:

  • A textfile with the list of packages that should be activated
  • A backup of the packages that were removed in the next state

This information is enough to get back from one state to the previous one. You can then repeat that process and get as far back as you need.

So, the simple solution here is to only remove the oldest states and never add “holes” in the history. This way we can always go back to any one of the remaining states if needed.

I think it makes sense to start by setting up this simple strategy, and integrate it in Haiku (maybe initially with a manual trigger, something like “pkgman clean-old-states”).

Then we can see about doing further things later:

  • Merging states so we can keep an older one but delete intermediate versions,
  • Triggering this automatically in some way.
6 Likes

I believe the option to keep some old version, remove most of the following intermediary states until the last several ones is useful for Haiku developers. When somebody works on a ticket about some regression, he may want to keep the old state where the problem does not exist yet and then keep the last several problematic states.

Perhaps same tool could set/switch state and that will be the one when you boot.