| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In commit 446551c8 I changed MarkInstall to discard the candidate if the
candidate can't satisfy the dependency. This breaks interactive solvers
like aptitude which can change the candidate on-the-fly later.
In commit df77d8a5 I introduced this 'early' loop-breaking to begin with
which can't be that helpful for interactive solvers as well, but makes
perfect sense for non-interactives to stop them from exploring trees
which can't be satisfied, but it isn't perfect as ideally we would check
this before auto-installing the first dependency.
This commit therefore moves the loop into its own IsInstallOk hook so
that frontends can override this check if they want to and in exchange
removes the loop-breaking from MarkInstall itself and does it before any
dependency is installed.
Closes: 740750
|
|
|
|
|
|
|
|
| |
Hooked checks could be influenced by AutoInst as a lot can happen
between a call without and one with this bit set. The real cache-hit
check is above this call already. Individual hooked checks can then
inspect the state if they want to cache. Calling them multiple times
shouldn't be a problem either way.
|
|
|
|
|
| |
Git-Dch: Ignore
Reported-By: gcc -Wsuggest-attribute={pure,const,noreturn}
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
| |
Reported-By: gcc -Wunused-parameter
Git-Dch: Ignore
|
|
|
|
|
| |
Git-Dch: Ignore
Reported-By: gcc -Wmissing-declarations
|
|
|
|
|
| |
Git-Dch: Ignore
Reported-By: gcc -Wpedantic
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| | |
When checking for negative dependencies in MarkInstall() ensure that
only dependencies that are relevant (i.e. getting installed) are
checked.
|
|/
|
|
|
|
|
|
|
| |
If a (Pre-)Depends can't be satisfied there is no point in keeping the
candidate as is as it is impossible to find a solution for it, so we can
just as well reset the candidate to the currently installed version.
We avoid trying to install this impossible candidate later on this way.
Closes: #735967
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We can't remove packages which are held back by the user with a hold, so
marking them (or its dependencies) as garbage will lead our autoremover
into madness – and given that the package is important enough that the
user has held it back it can't be garbage (at least at the moment), so
even if a front-end wants to use the info just for information display
its a good idea to not consider it garbage for them.
Closes: 724995
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The rational from the buglog:
> The problem here is that the Priority field in one of the Packages files
> is incorrect due to a mishap with reprepro configuration, […] the
> amd64 version is Priority: standard but the arm64 version is Priority:
> optional (and has a stray "optional: interpreters" field).
> […]
> However, Priority is a rather weak property of a package because it's
> typically applied via overrides, and it's easy for maintainers of
> third-party repositories to misconfigure them so that overrides aren't
> applied correctly. It shouldn't be ranked ahead of choosing packages
> from the native architecture. In this case, I have no user-mode
> emulation for arm64 set up, so choosing m4:arm64 simply won't work.
This effectly makes the priority the least interesting data point in
chosing a provider, which is in line with the other checks we have
already order above priority in the past and also has a certain appeal by
the soft irony it provides.
Closes: #718482
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Multi-Arch: same packages can be co-installed, but need to have the same
version for all installed packages (aka "siblings"). Otherwise the
unsynced versions will fight against each other and the auto-install as
wel as the problem resolver will later have to decide between holding the
packages or to remove one of the siblings (usually a foreign) taking a
bunch of packages (like the entire foreign setup) with them.
The idea here is now to be more pro-active: MarkInstall will fail for
a package if the siblings aren't synced, so we don't allow a situation
in which a resolver has to decide if to hold or to remove-upgrade under
the assumption that the remove-upgrade decision is always wrong and
doesn't deserve to be explored (expect valid out-of-syncs of course).
Thats a pretty bold move to take for a library which is used by
different solvers so this check is done in IsInstallOk and can be
overridden if front-ends want to.
|
|\
| |
| |
| |
| | |
Conflicts:
debian/changelog
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Used to work until a certain (here unnamed) person came along and used
the wrong operator causing low-priority packages to be sorted above
high-priority packages while choosing a provider in commit
2b5c35c7bb915dbd46fefd7c79f05364ba22f93b from Nov 2011
|
|/
|
|
| |
debug output of Debug::pkgDepCache::AutoInstall=true
|
|
|
| |
- provide DepIterator::IsSatisfied as a nicer shorthand for DepCheck
|
|
|
|
| |
- prefer to install packages which have an already installed M-A:same
sibling while choosing providers (LP: #1130419)
|
| |
|
|
|
|
| |
- don't call MarkInstall with the FromUser flag set for packages
which are dependencies of APT::Never-MarkAuto-Sections matchers
|
|
|
|
| |
- ignore negative dependencies applying in the same group for
M-A:same packages on the real package name as self-conflicts
|
|
|
|
| |
version (or none as we have no versioned provides in debian) and not
if the version of the provider matches
|
|
|
|
|
| |
- clearly separate 'positive' and 'negative' dependencies and
their upgrade-resolution tries in MarkInstall and especially don't
treat Conflicts differently compared to Breaks here
|
|
|
|
| |
- No Immediate configuration (see above)
- Not automatically installed during dist-upgrade
|
|
|
|
| |
- if a M-A:same package is marked for reinstall, mark all it's installed
silbings for reinstallation as well (LP: #859188)
|
| |
|
|
|
|
| |
- implicit conflicts (for multiarch) are supposed to conflict
only with real packages, not with virtual providers
|
|
|
|
|
|
|
|
| |
- prefer native providers over foreigns even if the chain is foreign
The code preferred real over virtual packages and based on priorities.
This is changed in so far that a real package from any arch is preferred
over any virtual provider and if priorities doesn't help in choosing the
best provider we choose it based on architectures
|
| |
|
| |
|
|\ |
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | | |
done on the mirco-optimazation level, so lets fix them:
(performance) Possible inefficient checking for emptiness.
(performance) Prefer prefix ++/-- operators for non-primitive types.
|
| | |
| | |
| | |
| | | |
depcache by caching the install-recommends and install-suggests
values
|
| | |
| | |
| | |
| | | |
size are pretty unlikely for now, but we need it for deb
packages which could become bigger than 4GB now (LP: #815895)
|
|/ / |
|
|\| |
|
| |
| |
| | |
- change default of APT::AutoRemove::SuggestsImportant to true
|
| |
| |
| | |
can't be removed the installation of the breaker fails.
|
| | |
|
| |
| |
| |
| | |
- use a boolean instead of an int for Add/Remove in AddStates
similar to how it works with AddSizes
|
| |
| |
| |
| | |
pseudo-package related and/or private
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| | |
use the internal resolver can now be used also with external
ones as the usage is hidden in between the old API
* provide two edsp solvers in apt-utils:
- 'dump' to quickly output a complete scenario and
- 'apt' to use the internal as an external resolver
|
| |
| |
| |
| |
| |
| |
| | |
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)
|
| |
| |
| |
| | |
will not use the default internal resolver later on
|
| |
| |
| |
| |
| |
| | |
based on a very early draft for EDSP by Stefano
APT can now write a scenario as well as load most stuff from it.
|