Desktop Team meeting, 2008-08-14
mdz at ubuntu.com
Sat Aug 16 17:26:25 BST 2008
On Fri, Aug 15, 2008 at 10:36:07PM +0200, Michael Vogt wrote:
> We currently have 2012 packages with the tag "apport-package" in
> launchpad. Of these, 963 are open (not invalid, won't fix or fix
> released). I looked at the most recent bugs to get a idea what
> those are about and found:
Thanks for this analysis.
> (1) maintainer failure because of syntax error/incorrect use of
> programms/diverts: #258353, #257522, #257490, #257213, #257162,
> #257131, #257003, #256930, #254969
> (2) file overwrite issues: #257736, #257299, #257244, #257133, #256743,
> (3) pkgs/programms with default that cause the maintainer scripts to fail
> when they install: #258042, #257989, #257832, #257737, #257527,
> #257142, #257040, #256737, #256423
> (4) local customization/hardware that causes breakage: #257989, #257745,
> #257375, #256987, #256968, #235164, #256461, #256276
> (5) unknown: #257418, #257386, #256766, #256653, #256454, #256204, #256184
> I made the classification up on the spot and ordered by "usefulness"
> for us. Category 1 and 2 are bugs that can be fixed or at least
> diagnosed with the information in the bugreports.
> Category 3 is bad default or bad recovery from problematic
> conditions. E.g. a package that needs to connect to a database fails
> when it can't for some reason (wrong passowrd) instead of re-trying or
> to write a debconf note that some more configuration is required. Or a
> package like java-doc that prompts the user to download some files
> into a location and will fail if those files are not available.
> Category 4 is problematic, some stuff like pycentral not overwriting
> local python files could be improved (or we could provide a way to
> override this restriction on dist-upgrades). Some others like "fork()"
> failures because of low mem are much harder to deal with (or
> filesystem corruption).
> Catgeory 5 are the ones that I found no useful information in. Stuff
> like "capplet-data postinst failed with error code 1" without any
> further indication what went wrong.
> From looking at this (unscientific) sample it seems like we have some
> noise in the reports, but also a lot of valueable information that
> shows us problematic packages. We should probably discuss better
> server side filtering on the next UDS too to reduce the noise.
1, 2 and 3 (total over 60% of the sample) look like things which should be
fixed. Package installation failures are treated very seriously by the
package management tools, there is no rollback and the user is left with a
persistent problem on their system which must be fixed.
If we can ensure that they are reported on the appropriate packages, and
filter out the most common cases for the other 40%, this wolud be a great
More information about the ubuntu-desktop