apt/test/integration/test-no-fds-leaked-to-maintainer-scripts, branch master

Fix test due to display change in ls (coreutils 8.32)

2020-07-07T17:13:38Z

The test runs ls on the opened fds and greps the result for 'root root' which is how ls (<= 8.30) used to report user and group for these. Now that Debian contains 8.32 it reports user and group of the process owning them (supposedly). grepping for both unbreaks the test. lr-x------ 1 root root 64 Jul 7 19:07 0 -> 'pipe:[10458045]' lrwx------ 1 root root 64 Jul 7 19:07 1 -> /dev/pts/12 lrwx------ 1 root root 64 Jul 7 19:07 2 -> /dev/pts/12 lr-x------ 1 root root 64 Jul 7 19:07 3 -> /proc/1266484/fd vs (assuming user:group is david:david) lr-x------ 1 david david 64 Jul 7 19:07 0 -> 'pipe:[10458045]' lrwx------ 1 david david 64 Jul 7 19:07 1 -> /dev/pts/12 lrwx------ 1 david david 64 Jul 7 19:07 2 -> /dev/pts/12 lr-x------ 1 david david 64 Jul 7 19:07 3 -> /proc/1266484/fd

Don't expect duplicated dpkg status-fd messages

2018-09-11T11:08:58Z

The progress reporting relies on parsing the status reports of dpkg which used to repeat being in the same state multiple times in the same run, but by fixing #365921 it will stop doing so. The problem is in theory just with 'config-files' in case we do purge as this (can) do remove + purge in one step, but we remove this also for the unpack + configure combination althrough we handle these currently in two independent dpkg calls.

fix testcase expecting incorrect remove log from dpkg

2016-11-09T15:18:54Z

dpkg 1.18.11 includes: * Do not log nor print duplicate dpkg removal action. We print “Removing ()” lines and log remove action twice when purging a package from frontends, because they usually first call --remove and then --purge sequentially. When purging a package which is already in config-files (i.e. it has been removed before), do not print nor log the remove action.

test: More portable check for dpkg versions

2016-08-26T20:22:47Z

This check should work regardless if dpkg was installed by dpkg or by a native package manager like RPM or pkg. Gbp-Dch: ignore

test: Avoid use of /proc/self/fd

2016-08-26T20:17:55Z

Use /dev/fd in test-bug-712116-dpkg-pre-install-pkgs-hook-multiarch, skip test-no-fds-leaked-to-maintainer-scripts (it is not guaranteed that /dev/fd contains all file descriptors), and avoid the unneeded use of /proc/fd in another test case. Gbp-Dch: ignore

do dpkg --configure before --remove/--purge --pending

2016-08-23T09:32:23Z

Commit 7ec343309b7bc6001b465c870609b3c570026149 got us most of the way, but the last mile was botched by having the pending calls in the wrong order as this way we potentially 'force' dpkg to remove/purge a package it doesn't want to as another package still depends on it and the replacement isn't fully installed yet. So what we do now is a configure before remove and purge (all with --no-triggers) and finishing off with another configure pending call to take care of the triggers. Note that in the bugreport example our current planner is forcing dpkg to remove the package earlier via --force-depends which we could do for the pending calls as well and could be used as a workaround, but we want to do less forcing eventually. Closes: 835094

disable explicit configuration of all packages at the end

2016-08-10T21:51:35Z

With b4450f1dd6bca537e60406b2383ab154a3e1485f we dropped what we calculated here later on and now that we don't need it in the meantime either we can just skip the busy work by default and expect dpkg to do the right thing dropping also our little "last explicit configures" removal trick introduced in b4450f1dd6bca537e60406b2383ab154a3e1485f. This enables the last of a bunch of previously experimental options, some of them existing still, but are very special and hence not really worth documenting anymore (especially as it would need to be rewritten now entirely) which is why the documentation is nearly completely dropped. The order of configuration stanzas in the simulation code changes slightly as it isn't concerning itself with finding the 'right' order, but any order is valid anyhow as long as the entire set happens in the same call.

don't purge directly, but remove and do purge at the end

2016-08-10T21:18:04Z

If we want a package to be purged from the system tell dpkg in the ordering (if it has to touch it explicitly) to remove it and cover the purging of the config files at the end with a --purge --pending call. That should help packages move conffiles around between packages correctly even if the user is purging packages directly in big actions like dist-upgrades involving many packages.

don't explicitly configure the last round of packages

2016-06-08T15:31:45Z

We end our operation by calling "dpkg --configure -a", so instead of running a (big) configure run with all packages mentioned explicitly before this, we simply skip them and let them be handled by this call implicitly. There isn't really an observeable gain to be had here from a speed point, but it helps in avoiding an (uncommon) problem of having a too long commandline passed to dpkg, which we would split up (probably incorrectly).

tests: support spaces in path and TMPDIR

2015-12-19T22:04:34Z

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