| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An interactive tool like aptitude needs these flags current far more
often than we do as a user can see them in apt only in one very well
defined place – the autoremove display block – so we don't need to run
it up to four times while a normal "apt install" is processed as that is
just busywork.
The effect on runtime is minimal, as a single run doesn't take too long
anyhow, but it cuts down tremendously on debug output at the expense of
requiring some manual handholding.
This is opt-in so that aptitude doesn't need to change nor do we need to
change our own tools like "apt list" where it is working correctly as
intended.
A special flag and co is needed as we want to prevent the ActionGroup
inside pkgDepCache::Init to be inhibited already so we need to insert
ourselves while the DepCache is still in the process of being built.
This is also the reason why the debug output in some tests changed to
all unmarked, but that is fine as the marking could have been already
obsoleted by the actions taken, just inhibited by a proper action group.
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
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.
|
