summaryrefslogtreecommitdiff
path: root/apt-pkg/depcache.cc
Commit message (Collapse)AuthorAgeFilesLines
* Propagate protected to already satisfied dependenciesDavid Kalnischkies2020-05-181-33/+36
| | | | | | | | The previous commit deals with negative, now we add the positive side of things as well which makes this a recursive endevour. As we can push the protected flag forward only if a single solution for a dependency exists it is easy for trees to not get it, so if resolving becomes difficult it won't help at all.
* Propagate protected to already satisfied conflictsDavid Kalnischkies2020-05-181-30/+82
| | | | | | | | | | | If we propagate protected e.g. due to a user request we should also act upon (at the moment) satisfied negative dependencies so that the resolver knows that installing this package later is not an option. That the problem resolver is trying bad solutions is a bug by itself which existed before and after and should be worked on. Closes: #960705
* Deal with protected solution providers firstDavid Kalnischkies2020-05-181-3/+6
| | | | | | | | For positive dependencies this isn't giving much as the dependency should already be satisfied by such a provider if its protectiveness would help, but it doesn't hurt to check them first and for negative dependencies it means that we check those first which are the most likely to fail to be removed – which is a good idea.
* Move the MarkInstall helpers into static functionsDavid Kalnischkies2020-05-181-59/+72
| | | | | | | | Reducing the scope of these helpers might allow us to move them elsewhere and share them or it is a rather pointless exercise, we will see where it leads us to later on. Gbp-Dch: Ignore
* Keep going if a dep is bad for user requests to improve errorsDavid Kalnischkies2020-05-181-18/+47
| | | | | | | | | | | | | | We exit early from installing dependencies of a package only if it is not a user request to avoid polluting the state with installs which might not be needed (or detrimental even) for alternative choices. We do continue with installing dependencies though if it is a user request as it will improve error reporting for apt and can even help aptitude not hang itself so much as we trim the problem space down for its resolver dealing with all the easy things. Similar things can be said about the testcase I have short-circuit previously… keep going test, do what you should do to report errors!
* Allow aptitude to MarkInstall broken packages via FromUserDavid Kalnischkies2020-05-081-5/+8
| | | | | | | | | | | | | | | | | | apt marks packages coming from the commandline among others as protected to ensure the various resolver parts do not fiddle with the state of these packages. aptitude (and potentially others) do not so the state is modified (to a Keep which for uninstalled means it is not going to be installed) due to being uninstallable before the call fails – basically reverting at least some state changes the call made before it realized it has to fail, which is usually a good idea, except if users expect you to not do it. They do set the FromUser option though which has beside controlling autobit also gained the notion of "the user is always right" over time and can be used for this one here as well preventing the state revert. References: 0de399391372450d0162b5a09bfca554b2d27c3d Reported-By: Jessica Clarke <jrtc27@debian.org> on IRC
* Protect a package while resolving in MarkInstallDavid Kalnischkies2020-04-271-8/+27
| | | | | | | | 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…
* Prefer upgrading installed orgroup membersDavid Kalnischkies2020-04-271-50/+48
| | | | | | | | In normal upgrade scenarios this is no problem as the orgroup member will be marked for upgrade already, but on a not fully upgraded system (or while you operate on a different target release) we would go with our usual "first come first serve" approach which might lead us to install another provider who comes earlier – bad if the providers conflict.
* Propagate Protected flag to single-option dependenciesDavid Kalnischkies2020-04-271-4/+20
| | | | | | | | | | | | | | | 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 MarkInstallDavid Kalnischkies2020-04-271-16/+23
| | | | | | | | 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 methodsDavid Kalnischkies2020-04-271-64/+101
| | | | | 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).
* Discard candidate if its dependencies can't be satisfiedDavid Kalnischkies2020-04-271-0/+17
| | | | | | We do pretty much the same in IsInstallOk, but here we have already set the state, so we have to unroll the state as well to sort-of replicate the state we were in before this MarkInstall failed.
* Refactor and reorder MarkInstall codeDavid Kalnischkies2020-04-271-134/+145
| | | | | | | This fixes no bugs per se, but the idea is to delay more costly changes and check easier things first. It e.g. inhibits the moving of the autobit until we are sure that this MarkInstall call isn't going to fail (e.g. because a dependency isn't satisfiable).
* Explore or-groups for Recommends further than firstDavid Kalnischkies2020-04-271-30/+35
| | | | | | | | | | | | | | MarkInstall only looks at the first alternative in an or-group which has a fighting chance of being satisfiable (= the package itself satisfies the dependency, if it is installable itself is not considered). This is "hidden" for Depends by the problem resolver who will try another member of the or-group later, but Recommends are not a problem for it, so for them the alternatives are never further explored. Exploring the or-group in MarkInstall seems like the better choice for both types as that frees the problem resolver to deal with the hard things like package conflicts.
* Discard impossible candidate versions also for non-installedDavid Kalnischkies2020-04-261-26/+21
| | | | | | | | We reseted the candidate for installed packages back to the version which is installed if one of the (critical) dependencies of it is not statisfiable, but we can do the same for non-installed packages by discarding the candidate which beside slightly helping the resolver also improves error messages generated by apt as a sideeffect.
* depcache: Remove deprecated functionsJulian Andres Klode2019-02-261-15/+0
|
* Fix typos reported by codespell & spellintianDavid Kalnischkies2018-08-291-1/+1
| | | | | | | | No user-visible change as it effects mostly code comments and not a single error message, manpage or similar. Reported-By: codespell & spellintian Gbp-Dch: Ignore
* Increase debug verbosity in `apt-get autoremove`Filipe Brandenburger2018-05-211-15/+18
| | | | | | | | | | | 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`.
* Remove obsolete RCS keywordsGuillem Jover2018-05-071-1/+0
| | | | Prompted-by: Jakub Wilk <jwilk@debian.org>
* Fix various typos reported by spellcheckersDavid Kalnischkies2018-05-051-5/+5
| | | | | Reported-By: codespell & spellintian Gbp-Dch: Ignore
* don't auto-switch candidate if installed is good enoughDavid Kalnischkies2017-12-131-0/+7
| | | | | | | If we perform candidate switching in requests like "apt install foo/bar" we should first check if the dependencies of foo from release bar are already satisfied by what is already installed before checking if the candidate (or switched candidate) would.
* Replace APT_CONST with APT_PURE everywhereJulian Andres Klode2017-08-241-3/+3
| | | | | As a follow up to the last commit, let's replace APT_CONST with APT_PURE everywhere to clean stuff up.
* support compressed extended_states file for bug triageDavid Kalnischkies2017-07-261-4/+4
| | | | | | This file isn't compressed by default, but it might be compressed by a bugreporter and uncompressing it is extra work apt could do just as well on the fly as needed just like it does for the dpkg/status file.
* Reformat and sort all includes with clang-formatJulian Andres Klode2017-07-121-16/+16
| | | | | | | | | | | | | 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 includeJulian Andres Klode2017-07-121-1/+0
| | | | | Including cacheiterators.h before pkgcache.h fails because pkgcache.h depends on cacheiterators.h.
* fix various typos reported by codespell & spellintianDavid Kalnischkies2017-07-081-1/+1
| | | | | Reported-By: codespell & spellintian Gbp-Dch: Ignore
* fix various typos reported by spellintianDavid Kalnischkies2017-01-191-3/+3
| | | | | | | | 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
* clean up default-stanzas from extended_states on writeDavid Kalnischkies2016-07-221-13/+14
| | | | | | | | | | The existing cleanup was happening only for packages which had a status change (install -> uninstalled) which is the most frequent but no the only case – you can e.g. set autobits explicitly with apt-mark. This would leave stanzas in the states file declaring a package to be manually installed – which is the default value for a package not listed at all, so we can just as well drop it from the file.
* protect only the latest same-source providers from autoremoveDavid Kalnischkies2016-07-011-5/+34
| | | | | | | | | | | | | Traditionally all providers are protected providing something as apt can't know which of them is actually really providing the functionality for the user ensuring that we don't propose the removal of used stuff, but that is of course also keeping stuff around which could be removed. That can cause the collection of multiple old providers until the provided package is itself no longer needed (e.g. out-of-tree kernel modules). We combat this by marking providers only from the newest source package version so that old providers built by older versions of the same source package can be garbage collected.
* more explicit MarkRequired algorithm code (part 2)David Kalnischkies2016-06-301-116/+68
| | | | | | | | As the previous commit, this shouldn't change behavior at all, but beside being more explicit and perhaps faster its also considerably shorter (granted, mostly by if0-block elimination). Gbp-Dch: Ignore
* more explicit MarkRequired algorithm codeDavid Kalnischkies2016-06-301-19/+32
| | | | | | | | | | | | Piling everything in a single if statement always made my head wobble, but it hasn't even a benefit as the most common case of a package which isn't installed passes all of the old if and lands in the non-existent else-part of the inner if. So beside a subjective cleanup of what goes on this implementation should also be a bit faster. No change in behavior should be present. Gbp-Dch: Ignore
* if reading of autobit state failed, let write failDavid Kalnischkies2016-06-291-0/+5
| | | | | | | | If we can't read the old file we can't just move forward as that would discard potentially discard old data (especially other fields). We let it fail only after we are done writing the new file so a user has the chance to look into and merge the new data (which is otherwise discarded).
* factor out Pkg/DepIterator prettyprinters into own headerDavid Kalnischkies2016-04-281-9/+10
| | | | | | | | | The old prettyprinters have only access to the struct they pretty print, which isn't enough usually as we want to know for a package also a bit of state information like which version is the candidate. We therefore need to pull the DepCache into context and hence use a temporary struct which is printed instead of the iterator itself.
* respect user pinning in M-A:same version (un)screwingDavid Kalnischkies2016-04-281-2/+2
| | | | | | | | | | | | Using Pkg.CandVersion() here is wrong as its implementation will return a candidate based just on the default policy settings ignoring user preferences and otherwise set candidates (aka: it sidesteps the pkgDepCache). This causes M-A:same libraries to be detected as screwed even through they aren't, so that they end up being kept back. Reported-By: Felipe Sateler on IRC
* Do not mark packages for keep that we want to removeJulian Andres Klode2016-03-271-2/+5
| | | | | | | | | | | | | | | | | | | | | | If the package is marked for removal, keep it marked for removal and do not mark it for keep. If we mark it for keep, we some how later get to a different stage where it is marked for unpack instead of removal. In the example in the bug report, we would get a: SmartUnPack maas-region-controller-min:amd64 (replace version 2.0.0~alpha3+bzr4810-0ubuntu1 with Segmentation fault maas-region-controller-min:amd64 was marked for removal, but we changed it to keep and somehow it thinks that this is to be replaced now instead of removed (probably because the InstallVer != CandidateVer [with InstallVer = 0]). This fixes a regression introduced in release 1.2.7, commit: 0390edd5452b081f8efcf412f96d535a1d959457 Reported-by: LaMont Jones on IRC LP: #1562402
* do not strip epochs from state version stringsDavid Kalnischkies2016-03-161-5/+1
| | | | | | | | | | | The epoch stripping in this code is done since day one, but in other places we show a version epochs are not stripped. If epochs are present in packages they tend to be an important information which we can't just drop and especially can't drop "sometimes" as that confuses users and tools alike – so even if removing code in use for (close to) 18 years feels wrong, it is probably the right choice for consistency. Closes: 818162
* Fix bug where the problemresolve can put a pkg into a heisenstateMichael Vogt2016-03-151-0/+5
| | | | | | | | | | | | | | | | The problemresolver will set the candidate version for pkg P back to the current version if it encounters an impossible to satisfy critical dependency on P. However it did not set the State of the package back as well which lead to a situation where P is neither in Keep,Install,Upgrade,Delete state. Note that this can not be tested via the traditional sh based framework. I added a python-apt based test for this. LP: #1550741 [jak@debian.org: Make the test not fail if apt_pkg cannot be imported]
* prefer upgrading installed provides satisfierDavid Kalnischkies2016-01-251-0/+2
| | | | | | | | If you have chosen to install a foreign architecture provider it is more reasonable to keep this provider instead of removing this one to replace it with a newer version from a (usually) more preferred arch. Git-Dch: Ignore
* typo: run s#frontend#front-end# on all of src:aptDavid Kalnischkies2015-11-251-1/+1
| | | | | | The manpages were fixed by Justin B Rye, lets deal with the rest now. Git-Dch: Ignore
* sanify API to get 'the' candidate versionDavid Kalnischkies2015-11-041-1/+6
| | | | | | | | | This was discussed a while ago on #debian-apt and now that I see myself making this mistake lets bite the bullet and fix it in the easy way out version: Using a new name which fits with a similar named setter and deprecate the old method instead of 'hostily' changing API. Closes: #803471
* Cleanup includes after running iwyuMichael Vogt2015-08-171-1/+0
|
* Add GetPriority(VerIterator) to pkgDepCache::PolicyJulian Andres Klode2015-08-151-0/+2
| | | | | | | Also unify the case of considerFiles and ConsiderFiles to be ConsiderFiles in all cases. Gbp-Dch: ignore
* Deprecate SPtrArray<T> and convert everyone to unique_ptr<T[]>Julian Andres Klode2015-08-131-2/+2
| | | | More standardization
* C++11: Switch from auto_ptr to unique_ptrJulian Andres Klode2015-08-131-1/+1
| | | | This is nicer
* move manual-bit from 'oldlibs' pkg to its dependenciesDavid Kalnischkies2015-08-101-0/+28
| | | | | | | | | | | | | | | | | | | | | oldlibs used to be in APT::Never-MarkAuto-Sections so that old transition packages can be removed without causing the then (autoinstalled) renamed package to be autoremoved. It isn't ideal through as ideally you want the oldlibs package to be removed after nothing depends on it anymore regardless of if you have once installed it by hand or not – and if you had the package talking over (the dependencies) should carry the manual bit now as they are the real deal now. As an added bonus if the package has no dependencies because it is an oldlibs without a direct replacement you should move away from (like lib1 and lib2 are currently in the archive, but there will hopefully only be lib2 in the release) you get a lib1 marked as auto. If the user still needs the oldlibs package for some reason all he has to do is mark it as manual once as this move is only performed if a installed package changes its section from a not-Move-Autobit-Sections to a Move-Autobit-Sections.
* move APT::Never-MarkAuto-Sections handling to MarkDeleteDavid Kalnischkies2015-08-101-9/+35
| | | | | | | | | | | | Having the handling in MarkInstall means that it just effects installation of the metapackage, but if the dependencies change the new dependencies aren't protected (and the old dependencies are still protected for no 'reason'). Having it in MarkDelete means that if a metapackage is sheduled for removal all its currently installed dependencies are marked as manual, which helps against both as in this case there is no new/old and additionally if a user decides the installation of a metapackage was wrong he can just remove it explicitely avoid the manual marking entirely.
* mark again deps of pkgs in APT::Never-MarkAuto-Sections as manualDavid Kalnischkies2015-08-101-2/+7
| | | | | | | | | | | | | | | | | | In 50ef3344c3afaaf9943142906b2f976a0337d264 (and similar for other branches), while 'fixing' the edgecase of a package being in multiple sections (e.g. moved from libs to oldlibs in newer releases) I accidently broke the feature itself completely by operating on the package itself and no longer on its dependencies… The behaviour isn't ideal in multiple ways, which we are hopefully able to fix with new ideas as mentioned in the buglog, but until then the functionality of this "hack" should be restored. Reported-By: Raphaël Hertzog <hertzog@debian.org> Tested-By: Adam Conrad <adconrad@ubuntu.com> Closes: 793360 LP: 1479207 Thanks: Raphaël Hertzog and Adam Conrad for detailed reports and initial patches
* split-up Dependency structDavid Kalnischkies2015-08-101-6/+5
| | | | | | | | | | | | | | | | | | | | | Having dependency data separated from the link between version/package and the dependency allows use to work on sharing the depdency data a bit as it turns out that many dependencies are in fact duplicates. How many are duplicates various heavily with the sources configured, but for a single Debian release the ballpark is 2 duplicates for each dependency already (e.g. libc6 counts 18410 dependencies, but only 45 unique). Add more releases and the duplicates count only rises to get ~6 for 3 releases. For each architecture a user has configured which given the shear number of dependencies amounts to MBs of duplication. We can cut down on this number, but pay a heavy price for it: In my many releases(3) + architectures(3) test we have a 10% (~ 0.5 sec) increase in cache creationtime, but also 10% less cachesize (~ 10 MB). Further work is needed to rip the whole benefits from this through, so this is just the start. Git-Dch: Ignore
* bunch of micro-optimizations for depcacheDavid Kalnischkies2015-08-101-88/+82
| | | | | | | | DepCache functions are called a lot, so if we can squeeze some drops out of them for free we should do so. Takes also the opportunity to remove some whitespace errors from these functions. Git-Dch: Ignore
* show or-groups in not-installed recommends and suggests listsDavid Kalnischkies2015-08-101-12/+3
| | | | | | | | Further abstracting our new ShowList allows to use it for containers of strings as well giving us the option to implement an or-groups display for the recommends and suggests lists which is a nice trick given that it also helps with migrating the last remaining other cases of old ShowList.
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2026-05-14 12:29:18 +0000