Bug#784218: piuparts: Please document how to test upgrades of split packages
On 2015-05-04 11:15, Fabian Greffrath wrote: 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 Would have been helpful to give these command lines ... 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. That is definitively possible to test ... --distupgrade-to-testdebs will be needed, perhaps with one or two -d distro options (even '-d sid -d sid' could work) Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784218: piuparts: Please document how to test upgrades of split packages
Am Mittwoch, den 06.05.2015, 13:18 +0200 schrieb Andreas Beckmann: Would have been helpful to give these command lines ... 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 --distupgrade-to-testdebs will be needed, perhaps with one or two -d distro options (even '-d sid -d sid' could work) 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 signature.asc Description: This is a digitally signed message part
Bug#784218: piuparts: Please document how to test upgrades of split packages
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784218: piuparts: Please document how to test upgrades of split packages
Package: piuparts Version: 0.63 Severity: wishlist 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 -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (500, 'experimental'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages piuparts depends on: ii debootstrap 1.0.67 ii debsums 2.0.53 ii dpkg 1.17.25 ii lsb-release 4.1+Debian13+nmu1 ii lsof 4.86+dfsg-1 ii piuparts-common 0.63 ii python-debian0.1.27 pn python:any none Versions of packages piuparts recommends: ii adequate 0.12.1 Versions of packages piuparts suggests: pn schroot none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784218: [Piuparts-devel] Bug#784218: piuparts: Please document how to test upgrades of split packages
Hi Fabian, On Montag, 4. Mai 2015, Fabian Greffrath wrote: this is more or less a request to add documentation for a specific use case, because I believe if am using piuparts wrong. have you seen #717125 ? cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#784218: [Piuparts-devel] Bug#784218: piuparts: Please document how to test upgrades of split packages
Control: forcemerge -1 717125 Hi there, Am Montag, den 04.05.2015, 10:29 +0200 schrieb Holger Levsen: have you seen #717125 ? 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 signature.asc Description: This is a digitally signed message part
