summaryrefslogtreecommitdiff
path: root/apt-pkg
Commit message (Collapse)AuthorAgeFilesLines
* Replace whitelist/blacklist with allowlist/denylistJulian Andres Klode2020-08-041-1/+1
|
* Reorder config check before result looping for SRV parsing debugDavid Kalnischkies2020-07-021-11/+6
| | | | | 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.
* Add dependency points in the resolver also to providersDavid Kalnischkies2020-07-021-9/+40
| | | | | | | | | | | 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 propagationDavid Kalnischkies2020-07-021-3/+18
| | | | | | | | 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 resolvedDavid Kalnischkies2020-07-022-79/+101
| | | | | | | | | | | | | | | | | 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.
* Add basic support for the Protected fieldJulian Andres Klode2020-06-296-2/+26
| | | | This will be mapped to Important for the time being.
* Deduplicate EDSP Provides line of M-A:foreign packagesDavid Kalnischkies2020-06-141-9/+17
| | | | | | | | | | | | M-A:foreign causes Provides to apply to all architectures and as we wanted to avoid resolver changes for M-A those are done by explicitly creating these provides instead of forcing the resolvers to learn about this. The EDSP is a different beast though & we don't need this trick here especially as it leads to needless (but harmless) duplication. No sort+unique is done to avoid changing order (not that it should matter, but just to be sure), but the sets should be small enough to not make a huge difference either way.
* Tell EDSP solvers about all installed pkgs ignoring archDavid Kalnischkies2020-06-141-1/+1
| | | | | | | | We usually tell EDSP solvers only about architectures we are configured to treat as native/foreign, but the system could have packages from other architectures installed (even if very unlikely) which could influence the solution (e.g. requiring a removal) so we make sure to tell them.
* Do not sent our filename-provides trick to EDSP solversDavid Kalnischkies2020-06-141-5/+4
| | | | | | | | | | | | If package is installed via an explicitly given deb file we store the filename as a provides, so that the frontend can request the filename and get the usual "Selected foo instead of foo.deb" message. We do not need to trouble the EDSP solvers with that though as these provides are not valid in various ways and we have already solved the link between commandline and package (and version) for them. Closes: #962741
* Do not hardcode (wrong) group and mode in setup warningDavid Kalnischkies2020-06-061-3/+3
| | | | | | | | | | | | | | Partial directories are created with 0700, but the parent is 0755, while the error message would report 0700 for both… that isn't right and can be pretty confusing. Turns out that the messages aren't marked for translation, so no unfuzzing is required & we just leave it as untranslated for now. Especially as the more detailed error strings derived from errno are translated. Reported-By: Wakko Warner <wakko@animx.eu.org> Closes: #962310
* Deal with duplicates in the solution space of a depDavid Kalnischkies2020-06-031-22/+27
| | | | | | | | | | | | | While we process the possible solutions we might modify other solutions like discarding their candidates and such, so that then we reach them they might no longer be proper candidates. We also try to drop duplicates early on to avoid the simple cases of these which test-explore-or-groups-in-markinstall triggers via its explicit duplication but could also come via multiple provides. It only worked previously as were ignoring current versions which usually is okay expect if they are marked for removal and we want to reinstate them so the ProblemResolver can decide which one later on.
* Allow 20 instead of 10 loops for pkgProblemResolverDavid Kalnischkies2020-06-031-1/+2
| | | | | | | | Especially if a lot packages have to be removed due to not to explicitly expressed conflicts the problem resolver can take a few turns to remove them all. Allowing it to try a little longer if needed seems beneficial as the worst which can happen is that we now take two times as long to present an error message to the user.
* Consider if a fix is successful before claiming it isDavid Kalnischkies2020-06-021-18/+23
| | | | | | | | | For protected packages the "Fixing" done via KillList in the ProblemResolver will usually not happen as the state change is not allowed, so the debug message is just confusing and the resolver is needlessly looping here (which might push it over the edge), so if we didn't do our thing successfully here we short-circuit a bit to help the next iteration come to a solution.
* Consider protected packages for removal if they are marked as suchDavid Kalnischkies2020-05-291-1/+1
| | | | | | | | | | The pkgProblemResolver incorrectly skips protected packages while considering packages for removal, which was always wrong but is now a lot more visible as (potentially) far more packages are considered protected in their state. Note that the testcase shows that we need more changes to make this proper.
* Fix small memory leak in MethodConfigDavid Kalnischkies2020-05-271-1/+1
| | | | | | | | | We are leaking a d-pointer currently weighting a boolean in size and MethodConfig is instantiated in small numbers only, so nobody will actually notice a difference, but proper cleanup is important. Reported-By: clang LeakSanitizer References: 04ab37fecaf286f724bef2e0969d2b67ab5ac1b1
* Mark PatternTreeParser::Node destructor as virtualDavid Kalnischkies2020-05-251-0/+1
| | | | | | | | | The non-virtual base-destructor causes its derivate classes to leak tiny bits of memory otherwise. The header is private and not to be used outside of APT, so we can perform this tiny ABI break as there is no ABI to break. Reported-By: valgrind and clang -fsanitize=leak
* Allow FMV SSE4.2 detection to succeed on clangDavid Kalnischkies2020-05-251-3/+0
| | | | | | | | | As the builtins were used in the feature test also in the default branch clang fails to compile the test helpfully complaining that you need to compile with sse4.2 to use that while on gcc it is optimized out as unused code and produces only a warning for that… removing the code from the default branch fixes this problem, but we adapt the code some more to avoid compilers optimizing it out in the future just in case.
* Silence clang warning -Wstring-plus-intDavid Kalnischkies2020-05-252-5/+5
| | | | | | | | | | | | | ../apt-pkg/init.cc:137:39: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int] Cnf.CndSet("Dir::State", STATE_DIR + 1); ../apt-pkg/init.cc:137:39: note: use array indexing to silence this warning We have a few instances of that & it should be reasonably clear that we are not actually trying to append here, but ignoring or silencing this warning with an override is far more costly than just using what clang suggests here. Reported-By: clang Gbp-Dch: Ignore
* Ensure EDSP doesn't use a dangling architecture stringDavid Kalnischkies2020-05-251-4/+2
| | | | | | | | | | | ../apt-pkg/edsp.cc:861:23: error: object backing the pointer will be destroyed at the end of the full-expression [-Wdangling-gsl] const char *arch = _config->Find("APT::Architecture").c_str(); Compilers are probably optimizing it the way the patch does by hand now. Small string optimisation helps likely as well. Othwise that should have failed left and right as EDSP is used by experimental and such builders to talk to aspcud. Reported-By: clang
* Don't update candidate provides map if the same as currentDavid Kalnischkies2020-05-251-6/+6
|
* Don't set variables to conditionally override them 2 lines laterDavid Kalnischkies2020-05-251-5/+7
| | | | Gbp-Dch: Ignore
* Allow pkgDepCache to be asked to check internal consistencyDavid Kalnischkies2020-05-243-5/+106
| | | | | | | | For speed reasons pkgDepCache initializes its state once and then has a battery of update calls you have to invoke in the right order to update the various states – all in the name of speed. In debug and/or simulation mode we can sacrifice this speed for a bit of extra checking though to verify that we haven't made some critical mistake like #961266.
* Keep status number if candidate is discarded for kept back displayDavid Kalnischkies2020-05-231-0/+2
| | | | | | | | | | | | | | | | It looks like hack and therefore I wanted this to be a very isolated commit so we can find it & revert it easily if need be, but for now it seems to work. The idea is that Status is telling us how the candidate is in relation to the current installed version which is used to figure out if a package is "kept back" by the algorithm or not, but by discarding the candidate version we loose this information. Ideally we would keep better tabs on what we do to a package and why, but for now that seems okayish. It will cause the wrong version to be displayed though as if the package is installed the installed version becomes the candidate and hence (installed => installed) is displayed.
* Known-bad candidate versions are not an upgrade optionDavid Kalnischkies2020-05-231-1/+9
| | | | | | | | | | | | | If we have a negative dependency to deal with we prefer to install an upgrade rather than remove the current version. That is why we split the method rather explicitly in two in 57df273 but there is a case we didn't react to: If we have seen the candidate before as a "satisfier" of this negative dependency there is no point in trying to upgrade to it later on. We keep that info by candidate discard if we can, but even if we can't we can at least keep that info around locally. This "fixes" (or would hide) the problem described in 04a020d as well as you don't have to discard installations you never make.
* Reset candidate version explicitly for internal state-keepingDavid Kalnischkies2020-05-232-13/+17
| | | | | | | | | | | | | | | | | | | | | | | | For a (partially) installed package like the one MarkInstall operates on at the moment we want to discard the candidate from, we have to first remove the package from the internal state keeping to have proper broken counts and such and only then reset the candidate version which is a trivial operation in comparison. Take a look at the testcase: Now, what is the problem? Correct, git:i386. Didn't see that coming, right? It is M-A:foreign so apt tries to switch the architecture of git here (which is pointless, it knows that this won't work, but lets fix that in another commit) will eventually realize that it can't install it and wants to discard the candidate of git:i386 first removing the broken indication like it should, removing the install flag and then reapplies the broken indication: Expect it doesn't as it wants to do that over the candidate version which the package no longer had so seemingly nothing is broken. It is a bit of a hairball to figure out which commit it is exactly that is wrong here as they are all influencing each other a bit, but >= 2.1 is an acceptable ballpark. Bisect says 57df273 but that is mostly a lie. Closes: #961266
* Check satisfiability for versioned provides, not providing versionDavid Kalnischkies2020-05-191-1/+1
| | | | References: dcdfb4723a9969b443d1c823d735e192c731df69
* Recognize propagated protected in pkgProblemResolverDavid Kalnischkies2020-05-181-11/+12
| | | | | | | | | | | | | | | | | | | | | | | | | Turns out that pkgDepCache and pkgProblemResolver maintain two (semi) independent sets of protected flags – except that a package if marked protected in the pkgProblemResolver is automatically also marked in the pkgDepCache as protected. This way the pkgProblemResolver will have as protected only the direct user requests while pkgDepCache will (hopefully) propagate the flag to unavoidable dependencies of these requests nowadays. The pkgProblemResolver was only checking his own protected flag though and based on that calls our Mark* methods usually without checking return, leading to it believing it could e.g. remove packages it actually can't remove as pkgDepCache will not allow it as it is marked as protected there. Teaching it to check for the flag in the pkgDepCache instead avoids it believing in the wrong things eventually giving up. The scoring is keeping the behaviour of adding the large score boost only for the direct user requests though as there is no telling which other sideeffects this might have if too many packages get too many points from the get-go. Second part of fixing #960705, now with pkgProblemResolver output which looks more like the whole class of problem is resolved rather than a teeny tiny edgecase it was before.
* 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.
* Support negative dependencies in VCI::FromDependencyDavid Kalnischkies2020-05-181-75/+37
| | | | | | The important change is adding IsIgnoreable() as it will deal with self-conflicts and such, but while we are at it lets sprinkle in some refactoring.
* Move the MarkInstall helpers into static functionsDavid Kalnischkies2020-05-182-63/+74
| | | | | | | | 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-182-20/+49
| | | | | | | | | | | | | | 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!
* Skip reading data from tar members if nobody will look at itDavid Kalnischkies2020-05-181-28/+28
| | | | | | | | The variable this is read to is named Junk and that it is for usecases like apt-ftparchive which just looks at the items metadata, so instead of performing this hunked read for data nobody will process we just tell our FileFd to skip ahead (Internally it might still loop over the data depending on which compressor is involved).
* Properly handle interrupted write() call in ExtractTarDavid Kalnischkies2020-05-181-1/+1
| | | | | | With FileFd::Write we already have a helper for this situation we can just make use of here instead of hoping for the best or rolling our own solution here.
* Allow prefix to be a complete filename for GetTempFileDavid Kalnischkies2020-05-181-12/+24
| | | | | | | | | | | | | Our testcases had their own implementation of GetTempFile with the feature of a temporary file with a choosen suffix. Merging this into GetTempFile lets us drop this duplicate and hence test more our code rather than testing our helpers for test implementation. And then hashsums_test had another implementation… and extracttar wasn't even trying to use a real tempfile… one GetTempFile to rule them all! That also ensures that these tempfiles are created in a temporary directory rather than the current directory which is a nice touch and tries a little harder to clean up those tempfiles.
* Prefer use of O_TMPFILE in GetTempFile if availableDavid Kalnischkies2020-05-181-5/+12
| | | | | Not all filesystems implement this feature in all versions of Linux, so this open call can fail & we have to fallback to our old method.
* SECURITY UPDATE: Fix out of bounds read in .ar and .tar implementation ↵Julian Andres Klode2020-05-122-3/+10
| | | | | | | | | | | | | | | | | | | | | (CVE-2020-3810) When normalizing ar member names by removing trailing whitespace and slashes, an out-out-bound read can be caused if the ar member name consists only of such characters, because the code did not stop at 0, but would wrap around and continue reading from the stack, without any limit. Add a check to abort if we reached the first character in the name, effectively rejecting the use of names consisting just of slashes and spaces. Furthermore, certain error cases in arfile.cc and extracttar.cc have included member names in the output that were not checked at all and might hence not be nul terminated, leading to further out of bound reads. Fixes Debian/apt#111 LP: #1878177
* Allow aptitude to MarkInstall broken packages via FromUserDavid Kalnischkies2020-05-082-6/+9
| | | | | | | | | | | | | | | | | | 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
* Reinstate * wildcardsJulian Andres Klode2020-05-041-2/+5
| | | | | | | | | | | | Reinstate * wildcards as they are safe to use, but do not allow any other special characters such as ? or []. Notably, ? would overlap with patterns, and [] might overlap with future pattern extensions (alternative bracketing style), it's also hard to explain. Closes: #953531 LP: #1872200
* Protect a package while resolving in MarkInstallDavid Kalnischkies2020-04-272-10/+29
| | | | | | | | 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-272-5/+21
| | | | | | | | | | | | | | | 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-272-17/+24
| | | | | | | | 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-272-64/+113
| | | | | 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.
* Avoid -Wuseless-cast to intDavid Kalnischkies2020-04-261-2/+2
| | | | | Reported-By: gcc -Wuseless-cast Gbp-Dch: Ignore
generated by cgit v1.2.3-18-g5258 (git 2.32.0) at 2024-06-03 01:18:58 +0000