Revision 3 as of 2007-05-14 17:12:53

Clear message

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.


Automatically report package failures (overwrite problems, maintainer script failures etc) with libapt. It needs to be modified so that it can create a apport report when a package fails to install/upgrade/remove.


Use Cases




Outstanding Issues

* More robust handling of followup error chains when run with DPkg::StopOnError=false * adept has a modified copy of; discuss unification with standard libapt

BoF agenda and discussion

* Integration of apport problem report creation in libapt:

  • - we have to be careful as pretty much every package on the system may be in a in-between state (unpacked/configured) - no interactivity, no python-problem-report, etc.

libapt will write a small initial report with its own code. In the future we might have more use cases of additional information. For this, libapt should check a flag "Initial report only" which causes it to create the report with 0 permissions (first create, then chmod, then write); then frontends can complete it themselves. The dist-upgrader will set this flag and append its own logs and chmod to 600. This avoids races with the apport UI.

We will keep the current apport package_hook for the dist-upgrader for the following reasons:

  • It is not a packaged application, thus cannot install a package hook
  • apport UI is not enabled in feisty

package_hook needs to check for an already existing crash report from libapt (chmodded to 0) and update it accordingly

A nice feature in the future would be if libapt would be able to log the complete output of the dpkg session (or maybe even only stderr). Screen solved this problem already, we may look if we can lift some code from there.

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. Shouldn't be a problem as maintainer script are idempotent (according to policy); it is the same effect as the user just reattempting the upgrade.