Hi there,

this is more or less a request to add documentation for a specific use
case, because I believe if am using piuparts wrong.

I maintain a package "game" that is already in Debian unstable in
version 1.0-1. For the next upload, I have decided to split the
package into three, namely "game", "game-variant" and "game-data". The
former two are two variants of the game, whereas the latter contains
the common files for both variants. In the course of this split,
new Depends, Breaks and Replaces relations have been added as
(believed) appropriate and there are also some alternatives (for
the two different implementations of "game") that need to get managed
upon upgrade. You see, this is a mess. ;)

Now, if I want to test the upgrade path "game (sid) -> game + game-variant +
game-data", how would I invoke piuparts? Passing it only the .changes file
of my local build will only install and remove these three packages.
The upgrade is not performed, because two of these packages are not
found in the Debian archive. What I want to test is (1) install the
"game" package from sid and (2) upgrade to the packages given in the
.changes file. How do I achieve this?

Thank you very much!

 - Fabian

Hi Fabian,

have you seen #717125 ?


cheers,
	Holger

Hi there,

Am Montag, den 04.05.2015, 10:29 +0200 schrieb Holger Levsen:

no, but it gave some valuable pointers and I think our concerns are
similar enough to merge both bugs.
However, even after dozens of retries with different parameters, I
didn't get it to do what I expected. It either straightforward installed
the package from the local repo, because that had the higher version
number 1.0-2 (if used with the -a option) or it persisted to install
only the package from the Debian mirror, because of the "game=1.0-1"
command line passed over to apt-get.

I did not get it to first install the package from the Debian mirror,
then upgrade to the package from the local repo.

- Fabian

Would have been helpful to give these command lines ...

That is definitively possible to test ...

Am Mittwoch, den 06.05.2015, 13:18 +0200 schrieb Andreas Beckmann:

Sure, sorry.

$ grep piuparts ~/.bash_history
[...]
sudo piuparts ../chocolate-doom_2.1.0-2_amd64.changes
sudo piuparts ../chocolate-doom_2.1.0-2_amd64.deb ../chocolate-common_2.1.0-2_amd64.deb
sudo piuparts -d unstable ../chocolate-doom_2.1.0-2_amd64.changes
reportbug piuparts
[...]
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
information about the package, please find it prepared here:

http://anonscm.debian.org/cgit/pkg-games/chocolate-doom.git

As you can see from the command lines I posted above, I already tried
various combinations of these parameters. The symptoms were always the
same: With the "-a" parameter, apt always preferred to install the local
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.

- Fabian

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

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