| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
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!
|
|
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.
|
|
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.
|
|
This basically introduces ~33 flags in the output, but a package can
have only ~11 of them displayed at the same time. There is quiet a bit
of duplication also (an uninstalled package is by definition a
newinstall if its getting installed), but as this is debug output we are
better of showing them all in case one of them isn't set in a way it is
supposed to be set.
Git-Dch: Ignore
|
|
This doesn't allow all tests to run cleanly, but it at least allows to
write tests which could run successfully in such environments.
Git-Dch: Ignore
|
|
We use test{success,failure} now all over the place in the framework, so
its only consequencial to do this in the situations in which we test for
a specific output as well.
Git-Dch: Ignore
|
|
- do not call Mark{Install,Delete} from the autoremove code with
the FromUser bit set to avoid modifying the auto-installed bit
|
|
|
