summaryrefslogtreecommitdiff
path: root/apt-pkg/edsp.cc
AgeCommit message (Collapse)Author
2016-05-12edsp: warn if unexpected stanzas appear in the solutionDavid Kalnischkies
Unexpected are for examples removal requests for versions which aren't installed, installations of already installed versions & requests to install and remove a package at the same time.
2016-05-10edsp: support generic and solver-specific configsDavid Kalnischkies
The spec was slightly inconsistent if the preferences setting is available only as generic or specific setting & the code only supported the specific one, while for the strict-pinning was only generic… As the usual pattern for apt is to have both options we adapt the spec and code to support both as well. This also adds a purely informal "Solver" field so in case the request is saved in a file, we know to which solver the sent preferences apply. Closes: 823918
2016-05-10don't sent uninstallable rc-only versions via EDSPDavid Kalnischkies
Versions which are only available in dpkg/status aren't installable and apt doesn't pick them as candidate for this reason – for the same reason such packages shouldn't be sent to an external solver via EDSP. The packages are pinned to -1, but if the solver has strict pinning disabled it could end up picking this version anyhow – which is a request apt can not satisfy. Reported-By: Maximiliano Curia <maxy@debian.org> on IRC
2016-04-25edsp: ask policy engine for the pin of the version directlyDavid Kalnischkies
2016-02-16pass versioned provides to external solvers in EDSPDavid Kalnischkies
The EDSP output generated by apt didn't include the versioned provides information so that every provides looked like an unversioned one in the eyes of an external resolver.
2015-11-04sanify API to get 'the' candidate versionDavid Kalnischkies
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
2015-09-14do not discard new manual-bits while applying EDSP solutionsDavid Kalnischkies
In private-install.cc we call MarkInstall with FromUser=true, which sets the bit accordingly, but while applying the EDSP solution we call mark install on all packages with FromUser=false, so MarkInstall believes this install is an automatic one and sets it to auto – so that a new package which is explicitely installed via an external solver is marked as auto and is hence also up for garbage collection in a following call. Ideally MarkInstall wouldn't reset it, but the detection is hard to do without regressing in other cases – and ideally ideally MarkInstall wouldn't deal with the autobit at all – so we work around this on the calling side for now.
2015-09-14add Source-Version field for EDSPDavid Kalnischkies
The syntax of "Source" is different in EDSP compared to the the field of the same name in 'the rest' of Debian, so documented this accordingly and send the version as a new field.
2015-09-14implement dpkgs vision of interpreting pkg:<arch> dependenciesDavid Kalnischkies
How the Multi-Arch field and pkg:<arch> dependencies interact was discussed at DebConf15 in the "MultiArch BoF". dpkg and apt (among other tools like dose) had a different interpretation in certain scenarios which we resolved by agreeing on dpkg view – and this commit realizes this agreement in code. As was the case so far libapt sticks to the idea of trying to hide MultiArch as much as possible from individual frontends and instead translates it to good old SingleArch. There are certainly situations which can be improved in frontends if they know that MultiArch is upon them, but these are improvements – not necessary changes needed to unbreak a frontend. The implementation idea is simple: If we parse a dependency on foo:amd64 the dependency is formed on a package 'foo:amd64' of arch 'any'. This package is provided by package 'foo' of arch 'amd64', but not by 'foo' of arch 'i386'. Both of those foo packages provide each other through (assuming foo is M-A:foreign) to allow a dependency on 'foo' to be satisfied by either foo of amd64 or i386. Packages can also declare to provide 'foo:amd64' which is translated to providing 'foo:amd64:any' as well. This indirection over provides was chosen as the alternative would be to teach dependency resolvers how to deal with architecture specific dependencies – which violates the design idea of avoiding resolver changes, especially as architecture-specific dependencies are a cornercase with quite a few subtil rules. Handling it all over versioned provides as we already did for M-A in general seems much simpler as it just works for them. This switch to :any has actually a "surprising" benefit as well: Even frontends showing a package name via .Name() [which doesn't show the architecture] will display the "architecture" for dependencies in which it was explicitely requested, while we will not show the 'strange' :any arch in FullName(true) [= pretty-print] either. Before you had to specialcase these and by default you wouldn't get these details shown. The only identifiable disadvantage is that this complicates error reporting and handling. apt-get's ShowBroken has existing problems with virtual packages [it just shows the name without any reason], so that has to be worked on eventually. The other case is that detecting if a package is completely unknown or if it was at least referenced somewhere needs to acount for this "split" – not that it makes a practical difference which error is shown… but its one of the improvements possible.
2015-08-17Fix all the wrong removals of includes that iwyu got wrongMichael Vogt
Git-Dch: ignore
2015-08-17Cleanup includes after running iwyuMichael Vogt
2015-08-10hide implicit deps in apt-cache again by defaultDavid Kalnischkies
Before MultiArch implicits weren't a thing, so they were hidden by default by definition. Adding them for MultiArch solved many problems, but having no reliable way of detecting which dependency (and provides) is implicit or not causes problems everytime we want to output dependencies without confusing our observers with unneeded implementation details. The really notworthy point here is actually that we keep now a better record of how a dependency came to be so that we can later reason about it more easily, but that is hidden so deep down in the library internals that change is more the problems it solves than the change itself.
2015-08-10remove the compatibility markers for 4.13 abiDavid Kalnischkies
We aren't and we will not be really compatible again with the previous stable abi, so lets drop these markers (which never made it into a released version) for good as they have outlived their intend already. Git-Dch: Ignore
2015-06-16add d-pointer, virtual destructors and de-inline de/constructorsDavid Kalnischkies
To have a chance to keep the ABI for a while we need all three to team up. One of them missing and we might loose, so ensuring that they are available is a very tedious but needed task once in a while. Git-Dch: Ignore
2015-06-12store Release files data in the CacheDavid Kalnischkies
We used to read the Release file for each Packages file and store the data in the PackageFile struct even through potentially many Packages (and Translation-*) files could use the same data. The point of the exercise isn't the duplicated data through. Having the Release files as first-class citizens in the Cache allows us to properly track their state as well as allows us to use the information also for files which aren't in the cache, but where we know to which Release file they belong (Sources are an example for this). This modifies the pkgCache structs, especially the PackagesFile struct which depending on how libapt users access the data in these structs can mean huge breakage or no visible change. As a single data point: aptitude seems to be fine with this. Even if there is breakage it is trivial to fix in a backportable way while avoiding breakage for everyone would be a huge pain for us. Note that not all PackageFile structs have a corresponding ReleaseFile. In particular the dpkg/status file as well as *.deb files have not. As these have only a Archive property need, the Component property takes over this duty and the ReleaseFile remains zero. This is also the reason why it isn't needed nor particularily recommended to change from PackagesFile to ReleaseFile blindly. Sticking with the earlier is usually the better option.
2014-11-08guard ABI changes for SourcePkg/Ver in pkgCacheDavid Kalnischkies
Git-Dch: Ignore
2014-09-27store source name and version in binary cacheDavid Kalnischkies
Accessing the package records to acquire this information is pretty costly, so that information wasn't used so far in many places. The most noticeable user by far is EDSP at the moment, but there are ideas to change that which this commit tries to enable.
2014-06-18don't send pkg from an unknown architecture via EDSPDavid Kalnischkies
APT's cache can include packages from architectures dpkg has no knowledge about and can therefore not be installed for e.g. to allow easy lookups. There is no point in telling external solvers about them though and some of them might even be really talkative about ignoring them if we do.
2014-05-30support parsing EDSP requests Architecture{,s} stanzaDavid Kalnischkies
Adds also a small testcase for EDSP Git-Dch: Ignore
2014-05-30check exit status of external solversDavid Kalnischkies
Solvers are supposed to exit successfully even if they haven't found a solution, but a solver which fails drastically (like e.g. segfaults) should be detected and dealt with accordingly instead of ignored.
2014-05-04EDSP: add APT-Release field to Package stanzasStefano Zacchiroli
2014-05-04EDSP: add Source field to Package stanzasStefano Zacchiroli
2014-05-04EDSP: add Architecture(s) multi-arch fields to the Request stanzaStefano Zacchiroli
2014-05-04EDSP: bump protocol version to 0.5Stefano Zacchiroli
2014-03-13cleanup headers and especially #includes everywhereDavid Kalnischkies
Beside being a bit cleaner it hopefully also resolves oddball problems I have with high levels of parallel jobs. Git-Dch: Ignore Reported-By: iwyu (include-what-you-use)
2014-03-13warning: unused parameter ‘foo’ [-Wunused-parameter]David Kalnischkies
Reported-By: gcc -Wunused-parameter Git-Dch: Ignore
2013-03-20apt-pkg/edsp.cc: do not use stderr in WriteSolution at allMichael Vogt
2013-03-20apt-pkg/edsp.cc: do not spam stderr in WriteSolutionMichael Vogt
2012-10-13* apt-pkg/edsp.cc:David Kalnischkies
- include reinstall requests and already installed (= protected) packages in the install-request for external resolvers (Closes: #689331)
2012-06-11* apt-pkg/cacheiterators.h:David Kalnischkies
- add an IsMultiArchImplicit() method for Dep- and PrvIterator
2011-10-14merged lp:~donkult/apt/experimentalMichael Vogt
2011-09-19use forward declaration in headers if possible instead of includesDavid Kalnischkies
2011-09-13reorder includes: add <config.h> if needed and include it at firstDavid Kalnischkies
2011-05-17* apt-pkg/pkgcache.h:David Kalnischkies
- clean up mess with the "all" handling in MultiArch to fix LP: #733741 cleanly for everyone now
2011-05-17rename option APT::Solver::Name to simply APT::SolverDavid Kalnischkies
2011-05-10send the first line of the error message to the error list and fail a bitDavid Kalnischkies
more nicely and in order
2011-05-10fix SubProgress to accept a Percent parameter to update the CurrentDavid Kalnischkies
with the text as otherwise the update will be ignored
2011-05-09implement proper progress report with OpProgressDavid Kalnischkies
2011-05-07implement correct error reportingDavid Kalnischkies
2011-05-06undo the temporary progress reporting disabling which slipped into last commitDavid Kalnischkies
2011-05-03fix arguments for MarkInstall so packages are really marked as automaticDavid Kalnischkies
2011-05-03maybe Pre-Depends are checked if they write them as Pre-Depends andDavid Kalnischkies
not as PreDepends (doh!) …
2011-05-03tell the resolver a package is set on hold if it was set by the userDavid Kalnischkies
to Keep which happens for example if a user decides to "remove" a not installed package to forbid that it's part of the solution
2011-05-03implement external solver calling for upgrade and dist-upgrade, tooDavid Kalnischkies
2011-05-02doesn't execute autoremove marker setting if an external solver is calledDavid Kalnischkies
and instead rely on the Autoremove tagging to show us what could be done. (apt-internal-solver doesn't support this currently as it doesn't load the auto-information into the cache)
2011-05-02refactor: move solver execution into his own EDSP methodDavid Kalnischkies
2011-05-02reduce the buffer size so we get a sort of realtime progress reportDavid Kalnischkies
and print the time of output at the front of the progress report so we can see the delay
2011-05-02move the mapping generation to the top as the response reading isDavid Kalnischkies
currently waiting for the solver to complete and not non-blocking so we can generate the map while waiting for the solver
2011-05-02implement optional Progress report in EDSPDavid Kalnischkies
2011-04-25reorganize WriteScenario to add a WriteLimitedScenario in which a scenarioDavid Kalnischkies
can be limited to a subset of packages with only relevant dependencies