[Piuparts-devel] Bug#748796: piuparts: should not use dist-upgrade to check for a single package upgrade

[Yann Dirson]

On Wed, May 21, 2014 at 11:33:19PM +0200, Andreas Beckmann wrote:
> On 2014-05-21 13:08, Holger Levsen wrote:
> > On Dienstag, 20. Mai 2014, Yann Dirson wrote:
> >> http://bugs.debian.org/726799 shows that, while using dist-upgrade may
> >> be useful and can reveal problems, it does not test *just* the package
> >> upgrade it claims to be testing (sounds obvious, but well... ;).
> > 
> > Yes, it's obvious and I'd also argue it's obviously the right thing to do. So 
> > in fact I'm also considering to just close your bug (as not a bug, but design) 
> > and/or make it wishlist and close it then.
> > 
> > The usual way to upgrade the system is precisely to use "apt-get upgrade" or 
> > "apt-get dist-upgrade" and _not_ to upgrade a single package with "apt-get 
> > install $package/$version" - that's not a common real world use case.

Right, but that's the point of unitary testing in general: uncovering
potential problems before they bite.

Something that is more common is, on a machine which has not been
updated in a long time (yes, I occasionally get my hands on such
badly-maintained beasts, unfortunately), and there is an urgent task
to achieve that requires a new package or a new version of a package.

There, aptitude helps much in selecting the minimal set of packages to
upgrade, and the situation is much closer to single-package upgrade
than to dist-upgrade.  Not sure if there is a 100% accurate way to get
that minimal set without interaction, though, but if there were, that
could provide an interesting way of testing, that would be an
intermediate between install and dist-upgrade.


> IIRC piuparts even did the apt-get install way in the past - this
> usually failed if the upgrade involved a bigger transition that requires
> removal of some packages...
> 
> I might consider doing "apt-get install" upgrade tests (since they
> operate on "valid" systems as long as no --force-* options get involved)
> in addition to the "normal" distupgrade tests if they can uncover
> problems not found by distupgrade tests - but only if they don't create
> false positives (or these can be filtered automatically).
> And I'd like to see an example first...

Bug#726799 would have been uncovered and quickly characterized, when
testing an upgrade of shared-mime-info with gqo installed.

But well, it may well be that piuparts is not the best tool for this,
you know better :)