apt, branch 2.1.7

Release 2.1.7

2020-07-08T07:40:38Z

Detect pkg-config-dpkghook failure in tests to avoid fallback

2020-07-07T17:55:58Z

dpkg (>= 1.20.3) has better support for its own DPKG_ROOT resulting in architectures for the root being reported rather than the host system. Sadly the hookscript from pkg-config is not prepared for this resulting in our `dpkg --add-architecture` calls failing in the hook after dpkg has successfully added the architecture internally. The failure triggered fallback handling in the tests to work with an older version of dpkg with a different multi-arch implementation. So instead of doing the fallback, we ignore the failure if it seems like pkg-config-dpkghook is involved only producing a bunch of warnings to hint at this problem, but otherwise make the tests work again as it is a post-invoke script. References: #824774

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

Reorder config check before result looping for SRV parsing debug

2020-07-02T16:57:11Z

It isn't needed to iterate over all results if we will be doing nothing anyhow as it isn't that common to have that debug option enabled.

Reorder config check before checking systemd for non-interactive http

2020-07-02T16:57:11Z

If this option is disabled (which it is by default in Debian), we don't have to make the call and the checks around it. Not that it really matters that much as if it would we would be better checking only once.

Dutch program translation update

2020-07-02T16:57:11Z

Closes: #963008

Add dependency points in the resolver also to providers

2020-07-02T16:57:11Z

We were traditionally adding points for some dependency types to the real package, but we should also do it for providers of that package to help the resolver especially if the real package is for some reason not tagged for removal yet/anymore. While at it we ensure that the points are only attributed once for each package as especially with versioned provides a package can nowadays provide another many times and would hence acquire a lot of points.

Filter out impossible solutions for protected propagation

2020-07-02T16:57:11Z

If the package providing the given solution is tagged already for removal (or at least for "not installing") we can ignore this solution as a possibility as it is not one, which means we can avoid exploring the option and potentially forward the protected flag further if that helps in reducing the possibilities to a single one.

Delay removals due to Conflicts until Depends are resolved

2020-07-02T16:57:11Z

Marking a package for removal is fine if we know that we have to remove that package, but if we are in an alternative branch we might not go this route in the end and hence have a package pointlessly marked for removal which isn't questioned later on. We check if we are allowed to remove that package to avoid working on the positive dependencies if not, but we mark them for removal only after all the other dependencies are successfully resolved. In an ideal world we would let the problemResolver do its job on them, but the resolver might decide against doing the removal exploring another option like the next alternative, which might be a good idea, but is not the behaviour we had before, so that is the best we can do for now without changing the resolver drastically.

Merge branch 'patch-1' into 'master'

2020-07-01T07:02:50Z

Minor Catalan grammar typo See merge request apt-team/apt!123