apt/apt-pkg/depcache.h, branch 2.1.0Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=2.1.02020-04-27T11:51:46ZProtect a package while resolving in MarkInstall2020-04-27T11:51:46ZDavid Kalnischkiesdavid@kalnischkies.de2020-04-27T11:51:46Zurn:sha1:ae23e53f99ea0b7920744a7303fdee64796b7cce
Strange things happen if while resolving the dependencies of a package
said dependencies want to remove the package. The allow-scores test e.g.
removed the preferred alternative in favor of the last one now that they
were exclusive. In our or-group for Recommends we would "just" not
statisfy the Recommends and for Depends we engage the ProblemResolver…
Propagate Protected flag to single-option dependencies2020-04-27T11:49:19ZDavid Kalnischkiesdavid@kalnischkies.de2020-04-27T11:49:19Zurn:sha1:f76a8d331a81bc7b102bdd4e0f8363e8a59f64f6
If a package is protected and has a dependency satisfied only by a single
package (or conflicts with a package) this package must be part of the
solution and so we can help later actions not exploring dead ends by
propagating the protected flag to these "pseudo-protected" packages.
An (obscure) bug this can help prevent (to some extend) is shown in
test-apt-never-markauto-sections by not causing irreversible autobit
transfers.
As a sideeffect it seems also to help our crude ShowBroken to display
slightly more helpful messages involving the packages which are actually
in conflict.
Fail earlier on impossible Conflicts in MarkInstall2020-04-27T11:48:33ZDavid Kalnischkiesdavid@kalnischkies.de2020-04-27T11:48:33Zurn:sha1:347ea3f76ab263c729468e07b910ae027b66c9d8
MarkDelete is not recursive as MarkInstall is and we can not conflict
with ourselves anyhow, so we can move the unavoidable deletes before
changing the state of the package in question avoiding the need for the
state update in case of conflicts we can not deal with (e.g. the package
conflicts with an explicit user request).
Split up MarkInstall into private helper methods2020-04-27T11:47:08ZDavid Kalnischkiesdavid@kalnischkies.de2020-04-26T11:14:43Zurn:sha1:76498d46855c88b90316e4369ac32050db9a9d23
Should be easier to move the code bits around then and it helps in
documenting a bit what the blocks do and how they interact (or not).
apt-pkg: default visibility to hidden2020-02-26T19:34:54ZJulian Andres Klodejulian.klode@canonical.com2019-08-13T17:15:19Zurn:sha1:db678df196ccd8f9f6fb336706cf5701d1e53aa6Run unifdef -DAPT_{8,9,10,15}_CLEANER_HEADERS2019-06-12T13:02:55ZJulian Andres Klodejulian.klode@canonical.com2019-05-11T15:17:20Zurn:sha1:daa1352ed3d2bb4bc6aa0f0e7f22be3f0908942dMake APT::StringView public2019-06-11T12:45:55ZJulian Andres Klodejulian.klode@canonical.com2019-02-04T18:50:16Zurn:sha1:a6e86d51a0e32cdc91f2902b0d6b483af884dccadepcache: Remove deprecated functions2019-02-26T15:31:20ZJulian Andres Klodejulian.klode@canonical.com2019-02-26T12:10:14Zurn:sha1:7062f2a5a1bdb8c0e3c4b3b004e092046d1034baIncrease debug verbosity in `apt-get autoremove`2018-05-21T16:13:26ZFilipe Brandenburgerfilbranden@google.com2018-03-07T22:15:33Zurn:sha1:f0c2263dd702d646722b749f7b7d278d15c18c55
When running with Debug::pkgAutoRemove=yes, explain why certain packages
are being marked, either because they're marked essential/important or
because they match the blacklist from APT::NeverAutoRemove.
This should help troubleshoot cases where autoremove is not proposing
removal of packages expected to be up for removal.
Tested manually with `apt-get autoremove -o Debug::pkgAutoRemove=yes`.
Fix various typos reported by spellcheckers2018-05-04T22:34:27ZDavid Kalnischkiesdavid@kalnischkies.de2018-05-04T17:56:41Zurn:sha1:b12bdeaf8acd050c5526ecc05526db70df5fd485
Reported-By: codespell & spellintian
Gbp-Dch: Ignore