LibaptApportIntegration

Differences between revisions 3 and 7 (spanning 4 versions)
Revision 3 as of 2007-05-14 17:12:53
Size: 2516
Editor: p54A67AC1
Comment:
Revision 7 as of 2008-08-06 16:31:09
Size: 3992
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
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. 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).
Line 12: Line 15:
== Rationale == == Release Note ==

The apport-synaptic-integration makes our QA infrastructure more
complete by providing a way to give high quality feedback in case of
packaging problems.
Line 16: Line 23:
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.
Line 17: Line 28:

The collection mechanism will be implemented inside libapt.
Line 20: Line 33:
Libapt needs to 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.

The current apport 'package_hook' helper script is kept so that the
release-upgrader can still use it to attach log files.
Line 21: Line 42:

The code in apt that drives dpkg (dpkgpm.cc) will be modified so that
it can create a apport report. It will create them when a package
fails to install/upgrade/remove. The error message from dpkg that was
send over the statusfd will be writen to the report.

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).

We keep the apport 'package_hook' script, because the release-upgrader
is not a regular packaged application so 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.


== Future ==

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.
Line 24: Line 83:
* More robust handling of followup error chains when run with DPkg::StopOnError=false
* adept has a modified copy of dpkgpm.cc; discuss unification with standard libapt
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
Line 27: Line 91:
== BoF agenda and discussion == == Test Plan ==
Line 29: Line 93:
* 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.
Install a package with a broken maintainer script and wait for a
apport to show up.

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.

Summary

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).

Release Note

The apport-synaptic-integration makes our QA infrastructure more complete by providing a way to give high quality feedback in case of packaging problems.

Use Cases

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.

Scope

The collection mechanism will be implemented inside libapt.

Design

Libapt needs to 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.

The current apport 'package_hook' helper script is kept so that the release-upgrader can still use it to attach log files.

Implementation

The code in apt that drives dpkg (dpkgpm.cc) will be modified so that it can create a apport report. It will create them when a package fails to install/upgrade/remove. The error message from dpkg that was send over the statusfd will be writen to the report.

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).

We keep the apport 'package_hook' script, because the release-upgrader is not a regular packaged application so 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.

Future

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.

Outstanding Issues

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

Test Plan

Install a package with a broken maintainer script and wait for a apport to show up.


CategorySpec

LibaptApportIntegration (last edited 2008-08-06 16:31:09 by localhost)