apt/apt-pkg/packagemanager.cc, branch 2.1.11

Do not produce late error if immediate configuration fails, just warn

2020-10-21T09:47:29Z

We are seeing more and more installations fail due to immediate configuration issues related to libc6. Immediate configuration is supposed to ensure that an essential package is configured immediately, just in case some other packages use a part of the essential package that only works if that package is configured. This used to be a warning, it was turned into an error in some commit I can't remember right now, but importantly, the error missed a return, which means that ordering completed succesfully and packages were being installed anyway; and after all that happened successfully, we'd print an error at the end and exit with an error code, which is not super useful. Revert the error back to a warning such that the behavior stays the same but we do not fail (unless we mess up ordering which then gets caught by a consistency check later on. Closes: #953260 Closes: #972552 LP: #1871268

Merge pkgPackageManager::SmartUnpack

2020-02-26T13:12:34Z

Rename pkgSimulate::Go2 to pkgSimulate::Go

2020-02-26T13:10:47Z

Fix typos reported by codespell in code comments

2019-07-10T14:15:30Z

Also in old changelogs, but nothing really user visible like error messages or alike so barely noteworthy. Reported-By: codespell Gbp-Dch: Ignore

packagemanager: Remove deprecated functions

2019-02-26T15:31:20Z

Remove obsolete RCS keywords

2018-05-07T11:41:31Z

Prompted-by: Jakub Wilk

Reformat and sort all includes with clang-format

2017-07-12T11:57:51Z

This makes it easier to see which headers includes what. The changes were done by running git grep -l '#\s*include' \ | grep -E '.(cc|h)$' \ | xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/' To modify all include lines by adding a space, and then running ./git-clang-format.sh.

Drop cacheiterators.h include

2017-07-12T11:56:05Z

Including cacheiterators.h before pkgcache.h fails because pkgcache.h depends on cacheiterators.h.

schedule the correct side of the conflict for removal

2017-06-26T21:31:15Z

In complex situations in which we want to unpack a package which has a conflict/breaks on another package which must be removed due this conflict apt can decide to perform this remove earlier than initially planned. Problem: For three years apt wouldn't remove that package, but the package which has the conflict… The situation isn't very common and easily hidden as the package which is removed is unpacked a few actions later – it becomes visible for packages which protect themselves from removal through like systemd as the running init resulting in upgrade failures (#854041). Note that the package isn't purged, so data shouldn't be lost even if a user runs into a "hidden" case of it as long as the package sticks to the policy of removing data only on purge. Reaching this situation artificially is hard, which is why no testcase is included, as the situation is highly state dependent. Testing with "real" systems indicate that slight modifications in the installed packages set can make the bug not trigger. Regression-Of: 0eb4af9d3d0c524c7afdc684238aa263ac287449 Thanks: Michael Biebl for helping find this with countless tests

fix various typos reported by spellintian

2017-01-19T14:59:38Z

Most of them in (old) code comments. The two instances of user visible string changes the po files of the manpages are fixed up as well. Gbp-Dch: Ignore Reported-By: spellintian