Clean up cruft from system, especially after upgrades

2008-06-13 kamion: By and large this looks sensible, but I have a few comments:
 1) Please factor FIXME sections into the spec proper - I'm not going to approve a spec containing those. Anything that's a fundamental design issue should be resolved before the spec is approved. It's OK to have inline comments in parts of the spec indicating that the implementor needs to make a decision on something or other though.
 2) I think at least a basic GUI should be a deliverable for Intrepid, although I can certainly see that it makes sense not to do it first; could you clarify the implementation section to note that a GUI is a target for completion of this spec, rather than something deferred to future work?
 3) I think it would be useful to have a UI distinction between "always remove all cruft automatically" and "always remove all cruft of this type automatically". For instance, I'm usually happy to remove transitional packages automatically, but wouldn't want system-cleaner to automatically remove dotfiles from my home directory.
 4) The spec is a bit vague about exactly which items of cruft will be handled to start with. Are all the items in the rationale targets for completion of this spec, or only some? You should probably have some rough levels of importance.

2008-06-17 kamion: Much better, thanks! Approved.

2008-07-01 michael: I really like your point under Rationale about changes to defaults such as relatime. The main thing that keeps me installing fresh instead of upgrading is the worry of losing improved configuration files for already installed/configured packages or files (including grub, fstab, and compiz). Would you mind adding an example of this as a Use Case? It would be optimal if some utility (maybe this is outside of the scope of cleanup-cruft) could detect at upgrade (perhaps at the package level) when you have a value at the old default which has a new default, and prompt to update to the new defaults. Second best, if it can't know the old default, would be to at least prompt the user about the new defaults and allow them to accept or deny, or at least point them to the configuration file/application to handle it themselves later.

2008-07-01 michael: Additionally, if you want assistance creating a GUI for this, I would be glad to help. Let me know. As kamion said it would be a nice deliverable, and having someone else to do it so you can work on the underlying functionality might make it more realistic.

2008-08-06 PhilipGanchev: Despite what the spec says, I think this should be part of the update manager UI. If uses are warned of the dangers of cleaning up, and asked to confirm, they will not feel the update manager is unsafe.

2008-09-22 BUGabundo: I just filled a wishbug against Update-manager that my be related to this:
https://bugs.launchpad.net/ubuntu/+bug/273049
[quote]When users upgrade to the development version using update-manager -d or do-release-upgrade -d stats should be collected and sent to some kind of archive (after user allows them to) so that a approximated size necessary can be calculated in order to prevent running out of free disk on future dist upgrades by users (either still on development versions or Stable releases).
A rough number can be the size of the packages plus the necessary amount unpack.
We could tie the old kernel clean up (last good kernel [1]) with update-manager so more disk can be freed up in case there ain't enough free disk.
This ticket groups from #106804, #221855 and "595473[/quote]
Of course this is Ibex+1, and this Blueprint is already assigned to Ibex