[Piuparts-devel] Bug#784218: piuparts: Please document how to test upgrades of split packages

[Andreas Beckmann]

On 2015-05-06 14:44, Fabian Greffrath wrote:

> sudo piuparts --bindmount /tmp/repo --testdebs-repo /tmp/repo --distupgrade-to-testdebs -a chocolate-doom
> sudo piuparts --bindmount /tmp/repo --testdebs-repo /tmp/repo --distupgrade-to-testdebs --do-not-verify-signatures -a chocolate-doom
> sudo piuparts --bindmount /tmp/repo --testdebs-repo /tmp/repo --distupgrade-to-testdebs --do-not-verify-signatures --install-recommends -a chocolate-doom
> sudo piuparts --bindmount /tmp/repo --testdebs-repo /tmp/repo --distupgrade-to-testdebs --do-not-verify-signatures --install-recommends -a -d sid chocolate-doom
> sudo piuparts --bindmount /tmp/repo --testdebs-repo /tmp/repo --distupgrade-to-testdebs --do-not-verify-signatures --install-recommends -a -d stable chocolate-doom
> sudo piuparts --bindmount /tmp/repo --testdebs-repo /tmp/repo --distupgrade-to-testdebs --do-not-verify-signatures --install-recommends chocolate-doom_2.1.0-1_amd64.changes 
> 
> Please note that chocolate-doom_2.1.0-1 is the version currently in sid
> and -2 is the version I prepared locally. In this version the package
> has been split from 1 into 5 binary packages. If you need more

if a single -d argument is given, piuparts by default runs 2 tests
subsequently:
* an install+remove+purge test (disable with --no-install-purge-test)
* an install+upgrade+remove+purge test (disable with --no-upgrade-test)

you are probably seeing the "wrong" test installing the "wrong" package,
since you seem to be primarily interested in the upgrade tests

... -d sid --no-install-purge-test --distupgrade-to-testdebs -a
chocolate-doom

should do what you want, otherwise it's a bug, send a logfile.
IIRC --distupgrade-to-testdebs should work on upgrade tests as well (but
maybe it is not even needed, --no-install-purge-test could be sufficient
to solve confusion between the two tests)

If you give 2 -d arguments, piuparts will perform distupgrade tests.


Interesting could also be and upgarde test (no distupgrade test) with

... --extra-old-packages=chocolate-doom -a NEWPACKAGE

to install one of the recently split off packages on a system with the
old one installed, without (explicitly) upgrading the old package name


> package with the higher package revision. When passed the .changes file,
> apt was always forced to install exactly this specific version by
> passing the "=$version" suffix.

Don't pass .changes files, it doesn't let you do fun stuff :-)
(this should be documented), use --testdebs-repo instead.


If you manage to run piuparts for your package split, would be nice if
you could write a small summary from a users point that we could include
in out documentation:

  "I recently split my package foobar into packages foo and bar and ran
   these piuparts tests to test if everything went right:

   For testing $THING1:
     piuparts ...
   For testing $THING2:
   ..."

Or however you see it fit.

Thanks.


Andreas