Many GB of old states can be collected in a few months, it can even cause out of disk space and software failure.
Concerning the issue of old package states I have thought about the issue a bit and the simplest thing is just to have a limit on the number of old states. Worrying about dates just over-complicates it. I think keeping 10 or 20 old states is reasonable. It should be managed by the package_daemon so users donât have to worry about it.
I fixed the bootloader speed issue related to this, this should be a lot simpler. Maybe I could knock it out before beta2.
If this simple method proves too simple for some reason we can make it better later.
3 Likes
I donât think there was a ticket related to cleaning the old package states so I have created one and assigned it to myself: https://dev.haiku-os.org/ticket/15915
3 Likes
It would be definetely helpful to be able to keep some marked old version even if it is older than 10 or 20 states from now for the sake of regression tests.
1 Like
I have a very simple idea here. Since old states are directories it is easy to drop a file in them. If a state directory has a keep file, it will not be deleted by the system. I donât think we have any GUI management around these states so I think this will have to be a âpower userâ feature. But we can try to add it to the User Guide too.
Sorry, but that feels like quite a hack. Until we have a nice GUI solution, it seems to be easier to explain the problem in the user guide and have people delete (very) old state folders themselves.
I use FilWip GUI manager to delete previuos system states (it manages to delete other stuff too). Currently, it provides no possibility to choose which previous system state to keep and which to delete.
Ideally, I would love to be able to delete unnecessary system state from the bootloader, bot probably it exceeds the purpose of a bootloader.
Why a file? Just use filesystem attributes, thatâs what theyâre meant for?
Also, do we really need a GUI and an ability for the user to select specific states?
As for going with dates, the reason is you can easily install and remove a few dozen packages in a day (letâs say if you embark in porting a complex app and discover lots of dependencies one at a time). If we based the deletion on number of packages, you would find out that maybe you can only go 4 hours back, which would be annoying.
There is another complication: state directories depend on the next ones, they are transactions that you need to revert one at a time and you canât skip one. So keeping only some directories and deleting others wouldnât really work, you can only delete the oldest ones. So I think the best we can do is a slider for âdelete all package states older than N weeks/monthsâ
2 Likes
perhaps we could think about a service to sync states with a cloud storage service like Dropbox, Google Storage/Drive, S3 and so on.
Pls donât yelling me about privacy and big corps and so 
it woulde be totally optional, we could narrow the choices to only those providers providing a transparent policy about data (these will be paid-only solutions for sure) and data could eventually be crypted during transport as well.
I have to admit: I like that feature on Mac 
Well I guess there is a good reason cleaning old states has not been done yet. I think it is annoying to not have it managed by the system, as do a lot of users. There may be a way to solve it nicely but I guess I donât know enough about how the states really work. Overall it seems the package system is so complex it is almost impossible to maintain. I find that kind of sad.
Sometimes it is nice to flesh things out but there are points where these bike-shed discussions become extremely demotivating.
In the current development situation could be useful to keep several previous states, for tracking regressions and kind of. But looking to a more âstableâ situation, and for the âaverage userâ (AKA: not a developer, or someone evolved in the development process), I guess that just keeping the previous state is enough. Maybe just a checkbox in the Repositories configuration.
That allows to going back if some update broke something, but keep low complexity.
Looking at other OS, they also allow to âgoing backâ to any previous state? Iâm using Xubuntu too and donât see that equivalent option. (not sure about Windows, but anyways, it had became a mess, so not sure if taking it as an inspiration for us 
)
Itâs simple really: just delete the oldest states.
The questions are not related to the package kit here, just how many of these states can we delete?
And then bikeshedding and feature creep happens: some people want to keep a year worth of states because they want to check for regressions. Others want just one week. Some crazy dev like me suggests using log2rotate or a similar algorithm even though itâs not possible. Someone says the problem is disk space, so you should just check that and delete packages automatically when the disk is full. Some poweruser says they want manual control on which states are kept or not.
Keep it simple: delete all old states and keep a month worth of them. At least we have something then. And we can improve on it later.
2 Likes
Well, on Windows you can always create restoration point after each install or update but this will take longer and a lot of more disk spaceâŚ
For Haiku developers, it is very useful. For other software developers a bit less but for a ânormalâ user, it is more IMHO a security feeling.
I think that the main problem comes that a lot of people are using nightlies when they could use the stable branch where there are less updates.
We are guilty as we often encourage them to do it but it is not the only reason.
People tend to think that the driver they are waiting for, 3D acceleration or even their fancy GTK app will appear magically next week in nightlies. Some are hoping that the bug they never reported will be miraculously fixedâŚ
They easily understand that Haiku canât provide drivers as fast as M$ or Apple where drivers are made by manufacturers and there is countless money and manpower anyway.
But they compare with small linux distros, forgetting that they donât have to develop the kernel either and despite appearances thereâs also a huge community hiding behind.
Haiku community is still quite small, aside of a little core, people not so involved. Even if we benefit from open source software, apps often donât run out of the box and have to be ported. So things are taking time.
I think that once main expectations fulfilled, people will be more to use stable branch where it shouldnât be a problem.
It will leave mostly developers on nightlies.
Then I guess that an option to wipe things older than 2 months will be ok for the most. For Haiku devs who may want to keep more states, the idea would be to move them periodically to an external storage like a DVD. There could even be an option in boot loader to get them from there.
Didnât know this about states, that they have to be walked back incrementally. If there is a guide describing package and state management, please let me know. Thank you all for your work on Haiku, itâs a really great OS.