apt/test/integration/test-apt-get-upgrade, branch masterDebians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=master2015-12-19T22:04:34Ztests: support spaces in path and TMPDIR2015-12-19T22:04:34ZDavid Kalnischkiesdavid@kalnischkies.de2015-12-15T16:20:26Zurn:sha1:3abb6a6a1e485b3bc899b64b0a1b7dc2db25a9c2
This doesn't allow all tests to run cleanly, but it at least allows to
write tests which could run successfully in such environments.
Git-Dch: Ignore
test for or-group choice behaviour in upgrade2015-04-10T20:29:08ZDavid Kalnischkiesdavid@kalnischkies.de2015-03-10T20:05:02Zurn:sha1:f51401eb51939bfc932519601c43822a0aa5e343
In #780028 we were discussing how the or-group order should be more
important than keep-back decisions of 'upgrade'. We have this behaviour,
but to ensure it stays this way lets add a test for it.
Git-Dch: Ignore
test exitcode as well as string equality2015-03-16T17:01:54ZDavid Kalnischkiesdavid@kalnischkies.de2015-03-09T23:59:44Zurn:sha1:25b86db159fbc3c043628e285c0c1ef24dec2c6e
We use test{success,failure} now all over the place in the framework, so
its only consequencial to do this in the situations in which we test for
a specific output as well.
Git-Dch: Ignore
tests: support 'installed' release in insertpackage2014-10-23T14:54:27ZDavid Kalnischkiesdavid@kalnischkies.de2014-10-23T09:37:49Zurn:sha1:10e100e59a96ea7b6834a139beab5d9d70180633
It is sometimes handy to have an installed package also in the archive,
but this was until now harder than it should as you had to duplicate the
lines, which is especially dangerous while writing the tests as it
easily happens that these two lines divert and so the same-but-different
version detection kicks in.
Git-Dch: Ignore
fix progress output for (dist-)upgrade calculation2014-09-26T22:10:05ZDavid Kalnischkiesdavid@kalnischkies.de2014-08-17T10:30:21Zurn:sha1:2a884c612b10b27f4be2cc6dd689bfe448d9361a
Previously, we had a start and a done of the calculation printed by
higher-level code, but this got intermixed by progress reporting from an
external solver or the output of autoremove code…
The higherlevel code is now only responsible for instantiating a
progress object of its choosing (if it wants progress after all) and the
rest will be handled by the upgrade code. Either it is used to show the
progress of the external solver or the internal solver will give some
hints about its overall progress. The later isn't really a proper
progress as it will jump forward after each substep, but that is at
least a bit better than before without any progress indication.
Fixes also the 'strange' non-display of this progress line in -q=1, while
all others are shown, which is reflected by all testcase changes.
fixup various UI issues in the test2013-10-09T12:02:42ZMichael Vogtmvo@debian.org2013-10-09T12:02:42Zurn:sha1:d029b71845cd10ecb46893627dfe6de669ba689dreally fix test2013-10-09T10:37:52ZMichael Vogtmvo@debian.org2013-10-09T10:37:52Zurn:sha1:60b3bf0ca99f868182567c143cf17b8d0a6191ccuse "insertpackage" instead of "buildsimplenativepackage"2013-10-09T09:01:18ZMichael Vogtmvo@debian.org2013-10-09T09:01:18Zurn:sha1:a8c2236baff38fdae5b28e4469a7b2a68e88e3b6add test for upgrade, upgrade --with-new-pkgs, dist-upgrade2013-10-09T05:58:31ZMichael Vogtmvo@debian.org2013-10-09T05:58:31Zurn:sha1:08d3d7e93e4aba1998dd89a8e10da5046ad7dcb6