Ubuntu Wiki

• Launchpad Entry: cleanup-cruft

• Created: 2008-06-02

• Contributors: LarsWirzenius

• Packages affected: update-manager

FIXME

• incorporate comments by ColinWatson on the blueprint whiteboard

• check the cruft package for additional ideas
• check what update-manager does now
• some cruft is more difficult to clean up after upgrades due to lack of context (e.g. no knowledge of previous state); libapt could record previous state in its extended_states file

• discuss the System -> Administration menu entry with mpt

Summary

Update-manager cleans up after upgrading a system, but does not get all the cruft. People who upgrade without update-manager (apt-get, aptitude, synaptic, adept, ...) don't have their systems cleaned up at all. This affects especially people participating in the development of Ubuntu.

This spec proposes extracting the cleanup code from update-manager into a new, independent tool, provisionally called system-cleaner, possibly still part of the same source tree, but usable without the update-manager user interface. Additionally this spec proposes augmenting the tool to provide a fuller, more satisfying cleaning experience.

Release Note

The new tool system-cleaner will remove cruft from the system: old kernel versions, transitional packages, unnecessary packages, and so on.

Rationale

Ubuntu (and Debian) work hard to make sure a once-installed system can always just be upgraded, without having to be re-installed. This works quite well, but sometimes cruft gets left behind:

• old kernels
• old library packages
• transitional packages
• packages installed because something depended on them, but now nothing does
• now-unsupported packages that used to be part of the default install
• deprecated dotfiles in user home directories
• packages that are removed, but not purged, and have configuration files
• .dpkg-old/new files (from dpkg conffile handling)
• random leftover files belonging to old versions of or removed packages
• changes the default installation, such as mount options (relatime)

This cruft doesn't harm the system, it merely takes up some space. Not always a lot of space, but it would be good to clean it up. Some things, like the ever-growing list of kernels, affect the user experience: there should be no need for the user to have more than one, working kernel, by default, in the normal situation.

According to its author, the update-manager program should not be used to clean up systems. Cleaning up is potentially dangerous, and if update-manager seems risky, people won't use it. Thus, a separate tool should be developed.

Use Cases

• Rene installed his Ubuntu server using Warty Warthog, and has been upgrading to every new release ever since, using update-manager. During the several years that has passed, every bit of the hardware has been replaced. He now has a long list of kernels to select from in the grub menu, some of which don't even boot anymore. He would like to know what he can safely remove.
• Edith installed her system using Hardy Heron, and is now developing Intrepid Ibex, upgrading with apt-get every day. She also often installs new stuff, to verify bugs reported against them. Her development system is starting to feel rather bloated from all the installed stuff, and she'd like to clean it up.

Assumptions

Design

There are many kinds of cruft. For example, the logic to remove old kernels is completely different from the logic to .dpkg.old files. Also, different kinds of cruft may need different kinds of attention from the user: perhaps one of the kernels is still needed in some situations?

All kinds of cruft can be handled by the same overall scenario:

1. identify cruft
2. warn user of cruft
3. get confirmation or rejection from user about each piece of cruft
4. remove cruft that is confirmed for removal

It should be possible for the user to specify "always remove all cruft automatically" once, of course, so that only the first and last step are actually taken.

The proposed design is thus based on plugins. Each plugin implements operations to identify cruft, and the main program then handles all the user interaction. Plugins will be bundled with the software, and are essentially invisible to the user, but separating them means they will be easier to develop and test. It is currently unclear whether other packages may add plugins: for example, the installer might add a plugin to add the relatime option to fstab, or it might be better and simpler to just include this plugin, too, in the system-cleaner package.

Cruft can be packages to purge or individual files to remove, or commands to run. The user will be presented with a list of cruft, and the reason they are considered cruft. The human-readable reasons are provided by the plugins.

Implementation

There is code in update-manager to do some of the cleanup. This needs to be used as a base.

Plugins are classes derived from a systemcleaner.Plugin base class. The classes are placed in /usr/share/system-cleaner/plugins, in Python modules (foo.py) or packages (foo/__init__.py). The plugin manager imports any such modules and packages and instantiates any plugin classes in them automatically.

The user interface will initially be purely command line based, with line-based interaction when the user needs to be queried. The internal design will allow for an event based user interface, so that a GUI can be added later.

UI Changes

Once the GUI exists, an entry to the System -> Administration menu will be added.

Migration

Users will be pointed at the new tool in release notes.

Test/Demo Plan

The short form of the test plan is:

• create instances of each released Ubuntu version (in chroot or kvm)
• upgrade them to hardy/intrepid
  • LTS to LTS
  • otherwise to each successive release
• run system-cleaner
• compare system before and after system-cleaner
  • file list in the filesystem
  • file contents
  • package list
• flag any differences that are not (manually) whitelisted
• verify that the system still boots

CategorySpec