apt/apt-pkg/deb, branch 1.7.0_rc1

Reorder progress report messages

2018-09-11T11:08:58Z

We are seeing 'processing' messages from dpkg first, so it makes sense to translate them to "Preparing" messages instead of using "Installing" and co to override these shortly after with the "Preparing" messages. The difference isn't all to visible as later messages tend to linger far longer in the display than the ealier ones, but at least in a listing it seems more logical.

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.

Process status-fd completely before finishing dpkg call

2018-09-11T11:08:58Z

Exiting the processing loop as soon as the dpkg process finishes might leave status-fd lines unprocessed which wasn't much of a problem in the past as the progress would just be slightly off, but now that we us the information also for skipping already done tasks and generate warnings if we didn't see all expected messages we should make sure we seem them all. We still need to exit "early" if dpkg exited unsuccessfully/crashed through as the (remaining) status lines we get could be incomplete.

Don't use invalid iterator in Fallback-Of handling

2018-08-29T15:50:31Z

cppcheck reports: (error) Iterator 't' used after element has been erased. The loop is actually fashioned to deal with this (not in the most efficient way, but in simplest and speed isn't really a concern here) IF this codepath had a "break" at the end… so I added one. Note that the tests aren't failing before (and hopefully after) the change as the undefined behavior we encounter is too stable. Thanks: David Binderman for reporting

Set DPKG_FRONTEND_LOCKED as needed when doing selection changes

2018-08-08T13:20:44Z

We forgot to set the variable for the selection changes. Let's set it for that and some other dpkg calls. Regression-Of: c2c8b4787b0882234ba2772ec7513afbf97b563a

Add support for dpkg frontend lock

2018-08-07T13:07:52Z

The dpkg frontend lock is a lock dpkg tries to acquire except if the frontend already acquires it. This fixes a race condition in the install command where the dpkg lock is not held for a short period of time between different dpkg invocations. For this reason we also define an environment variable DPKG_FRONTEND_LOCKED for dpkg invocations so dpkg knows not to try to acquire the frontend lock because it's held by a parent process. We can set DPKG_FRONTEND_LOCKED only if the frontend lock really is held; that is, if our lock count is greater than 0 - otherwise an apt client not using the LockInner family of functions would run dpkg without the frontend lock set, but with DPKG_FRONTEND_LOCKED set. Such a process has a weaker guarantee: Because dpkg would not lock the frontend lock either, the process is prone to the existing races, and, more importantly, so is a new style process. Closes: #869546 [fixups: fix error messages, add public IsLocked() method, and make {Un,}LockInner return an error on !debSystem]

Fix lock counting in debSystem

2018-06-13T21:36:08Z

debSystem uses a reference counted lock, so you can acquire it multiple times in your applications, possibly nested. Nesting locks causes a fd leak, though, as we only increment the lock count when we already have locked twice, rather than once, and hence when we call lock the second time, instead of increasing the lock count, we open another lock fd. This fixes the code to check if we have locked at all (> 0). There is no practical problem here aside from the fd leak, as closing the new fd releases the lock on the old one due to the weird semantics of fcntl locks.

Start pkg records for deb files with dpkg output

2018-05-11T15:58:46Z

It is easier to prepend our fields, but that results in confusion for things working on the so generated records as they don't start with the usual "Package" – that shouldn't be a problem in theory, but in practice e.g. "apt-cache show" shows these records directly to the user who will probably be more confused by it than tools.

Remove obsolete RCS keywords

2018-05-07T11:41:31Z

Prompted-by: Jakub Wilk

Fix various typos reported by spellcheckers

2018-05-04T22:34:27Z

Reported-By: codespell & spellintian Gbp-Dch: Ignore