On Wed, May 04, 2022 at 07:42:54AM +0200, Harald Dunkel wrote: > Hi folks, > > I think the main problem is pretty easy to describe: OpenBSD loses track > about what it had installed and cannot clean up its own files on a system > upgrade.
technically we are already tracking which files were installed or removed (see src/distrib/sets/lists files which are under cvs). but we can't just decide to delete any old files at upgrade time: user might still use them. the simpler example is libraries: at upgrade time, your packages are still "old" packages which might be still using "old" libraries. if the "still used" library is removed before you update your packages, the program will not run... if the program is your window-manager, a package providing a login_* method, or some server used to auth your users, you start having big problems. For now, I am thinking that *some* files might be removable at upgrade time. A naive approch would be to remove whole directories (assuming the content is fully owned by the system (like /usr/include or /usr/share/man), which might be hazardous assumption in the general case). but if the upgrades doesn't work/finish for some reason, the system might not be as usable as expected (which is bad). Removing only (some) "old" files means having a list of all files previously installed-but-no-more in the installer. and it might be a different list by arch (but it shouldn't hurt to try to remove /usr/include/g++/alpha-unknown-openbsd7.0/bits/atomic_word.h on amd64). Some numbers: since 2021-10-31 (last 6 months, about 1 release), I counted 369 files removed (only from src, not accounting xenocara). But some files were installed, next removed, and next reinstalled, so the list should be revisited (I only counted removed files). The main problem I am seeing would be maintaining such lists, and it necessary means manual addition to add only "safe" files to remove (no libraries at least). Currently, sets files are mostly maintained by deraadt@ (>70% of the commits). And I don't want to add more work on his side for that. -- Sebastien Marie
