I’ve just merged a change (in hrev59440) that implements cleaning up old states in the administrative directory in the Package Kit, and added it to pkgman. (I know some of you use FilWip to do this; this provides similar functionality in the default system, no need for a third-party application.)
The default (not configurable at present, but it could be made to be if really desired) is that it deletes all states older than 30 days (meaning the time the state was last modified, not the state’s timestamp itself), but keeps at least 10, even if they’re older than 30 days. (It also won’t delete the current state, if you’re booted into an older one, or any states newer than it, since they’re also needed in that case.)
pkgman defaults to prompting you at the end of any update, install, remove, etc. asking whether you want to do the cleanup, like this:
[system] Applying changes ...
[system] Changes applied. Old activation state backed up in "state_2026-03-03_10:21:32"
[system] Cleaning up ...
[system] Done.
Clean up 1 old state (47.03 MiB)? [yes/no] (yes) :
If there aren’t any states old enough to be removed, then you won’t get the prompt at all. SoftwareUpdater doesn’t do this yet, as there’s some discussion about what prompting it should do (if any), but that’s intended to be added in the future.
Thx Augustin for adding this, I do have a single concern about being selective about keeping real old packages. Sometimes a new library gets updated which reveals issues (either a bug in library or bug in unrelated app using the library). From users point of view they just see crashing in app, and it can take even years before a fix is made.
Case in point ffmpeg and Medo and media kit - it worked very stable with almost zero crashes until major ffmpeg update 18 months or so ago, and now Medo crashes consistantly after 5 seconds in ffmpeg lib during decoding videos (ticketed). Same impact in a picture album app i wrote (unpublished), crash via translation kit while decoding image (also ticketed). When I boot into much older package state, these apps are stable and usable. With latest state after ffmpeg update, they’re unusable. Hence why some apps are unpublished since they work on older package states and not newer. I’ve been doing 70 hour workdays for a while (work, building a house) and have had zero time to look for workaround (also hoping regression may disappear in next major ffmpeg update).
To work around the issue, I still keep really old package state around (> 12 months). People on nightlies may want to revisit an official beta and toggle between them. Automatically deleting packages older than 30 days prevents this work flow.
I have similar professional issue with libboost/asio at work, >=1.87 removes a feature our product depends on while <= 1.86 works fine. There are no resources currently to investigate workaround, so we stick with boost/asio 1.83. But with package autoupdates, apps will break.
Does the haiku package system allow 2 versions of a package to coexist? Eg. the same way a directory local .so gets chosen vs a system .so, wouldnt it be interesting to allow a directory local package to be chosen over a system package. Eg to use the example above with boost, can our app link only to libboost 1.83 while other apps use “latest” 1.87? This has limited usability since eventually an API change in dependant package breaks the older package (causing a ripple of old packages to coexist with chosen/old oackage version).
In case of boost, I could add a note in the 1.85.0 to keep around for this, all of the boost libraries can be co-installed, so no problem if you have multiple ones installed, you just have to make sure the right one is called by in your recipe/package creation. (PS latest as of writing is bootst 1.90.0).
The ticket created for your problem (#19420) has not seen much activity because nobody has found a way to reproduce it. So that’s why it takes “years” for a fix to be made for many of these crashes. Do you have any media files to share that reproduce the problem?
I can’t seem to find a ticket for this one.
I don’t think this regression had anything to do with the FFmpeg update, rather it’s the new allocator in Haiku itself exposing a problem that has likely been there for a long time. It’s probably a bug in the Media Kit’s use of FFmpeg rather than in FFmpeg itself. So I wouldn’t expect this to magically go away.
This is not really what the state system was designed for. You can just say “no” at the deletion prompt though, and whenever we get around to adding this to SoftwareUpdater, it sounds like it’ll probably have some option or other way to disable it.
Is the new mechanism checking if there is an Haiku hrev in states? With 10, we might be ok but , right after installing, we are usually firing up HaikuDepot to install software that we are used to and this can results in many empty states.