Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.
Packages affected: apt, update-manager
Apport provides a good mechanism to automatically collect problem reports. This mechanism should be used to automatically collect package failure information (overwrite problems, maintainer script failures etc).
Maurice is a ubuntu developer who made a mistake in the hotkeysetup postinst. With the new report mechanism he gets a good quality bugreport at the same day as he uploads the faulty package.
The collection mechanism will be implemented inside libapt.
The code in apt that drives dpkg (dpkgpm.cc) will be extended so that it can create a apport report when a package fails to install/upgrade/remove. This will ensure that the apt frontends (synaptic, aptitude, python-apt) will benefit from this integration automatically.
Libapt will write a small initial report with its own code. It will not use external libraries for this as the system maybe in a state where e.g. python is not usable. If a "DPkgPM::InitialReportOnly" flag is set, it will set chmod the report to have a "0" permission (first create, then chmod, then write). This is useful for frontends that want to add additional information to the report (e.g. the release-upgrader will want to attach its log files and then chmod to 0600 to make it visible for the apport UI).
The current apport 'package_hook' helper script is kept so that the release-upgrader can still use it to attach log files. Because the release-upgrader is not a regular packaged application it can not install a package hook on its own. It will also call apport-gtk manually because apport is disabled in feisty. The script 'package_hook' needs to check for an already existing crash report from libapt (chmodded to 0) and update it accordingly.
A very useful feature would be if libapt could log the complete dpkg session so that it could be attached. This logging must be fully opaque for the terminal that is logged and it must not interfere with applications like the dialog frontend in debconf. We should check screen or script for solutions to this problem.
Another feature would be if a maintainer script fails we could rerun it inside libapt with "sh -x " and capture the complete output fot the bugreport. In order for this to work, the terminal logging problem must be solved first. It should not be a problem as maintainer script are idempotent (according to policy); it is the same effect as the user just reattempting the upgrade.
No code has been written yet.
When libapt is run with "DPkgPM::StopOnError=False" we will get followup errors from dpkg for packages that depend on the failed package (because it is e.g. only unpacked, but not configured yet). A robust handling of followup error chains is required. A simple solution is to only log the first error in this case. A more elaborate solution will depend on https://blueprints.launchpad.net/ubuntu/+spec/maintainer-script-failures