[Piuparts-devel] how to handle partial upgrade problems?

[Andreas Beckmann]

Hi,

I wanted to write a long and technical email about this subject ... and
started over, doing it this way:

I started looking for partial upgrade problems some time ago.
Any *valid* mixture of packages from, for example, squeeze and wheezy
(i.e. all (Pre-)Depends/Breaks/Conflicts are fulfilled) should be
installable without errors, shouldn't it?
Since there are probably A LOT of these valid combinations, I've
restricted my testing to candidates that are potentially more error
prone: packages that ship the same filename or where a filename was
moved from pkg1 to pkg2.

There are two common error classes:
* pkg2 is missing a versioned Replaces: pkg1
  this usually results in a file overwrite error
* pkg2 is missing a versioned Breaks: pkg1
  this results in files disappearing from pkg1 after the sequence
  install pkg1, install pkg2, remove pkg2

If such bugs showed up on the upgrade paths tested by piuparts, they
have already been reported as release critical (and most of them have
been fixed long ago). But how should we handle these bugs in different
upgrade paths? As these are *valid* (at least w.r.t. not having
Breaks/Replaces that would forbid them) paths, shouldn't we properly
"invalidate" them?

I'd vote for filing them as RC bugs, too. We can never know which
upgrade path will be taken on a real system (with its unique set of
installed packages). And having the relationships tight from the
beginning will show less of these subtle errors after a release.

For those interested in numbers:
squeeze->wheezy file overwrites: 40  file disappearance: 84
wheezy->sid     file overwrites: 2   file disappearance: 10

These numbers qualify for a mass bug filing discussion, too. Would it be
appropriate to do a RC MBF here?
And if this is confirmed, I could need some help doing this.

Or better, piuparts could use some help to make bug reporting easier. We
have collected quite some bug templates (text files with some gaps) over
time, but it still needs a lot of manual work: substituting values
(distros, package names, versions), inserting log snippets, attaching a
compressed logfile, ... before this can go to submit at . And that's just
after reading the logfile, classifying the problem we found and
selecting the template ... not to forget checking the BTS for existing
reports (that may just need usertagging).


Thanks go to Ralf Treinen, dose-debcheck, http://edos.debian.net/, and
piuparts.

Cheers!

Andreas

And apologies for working on getting the RC bug count up, not down :-)