| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
|
|
|
|
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
|
|
When checking for negative dependencies in MarkInstall() ensure that
only dependencies that are relevant (i.e. getting installed) are
checked.
|
|
|
|
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
|
|
debug output of Debug::pkgDepCache::AutoInstall=true
|
|
|
|
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
|
|
- 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
|
|
|
|
|
|
|
|
size are pretty unlikely for now, but we need it for deb
packages which could become bigger than 4GB now (LP: #815895)
|
|
|
|
|
|
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
|
|
|
|
- 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
|
|
MarkInstall to be a bit more easy to read and possibily a bit faster -
and add a small testcase for these situations to ensure the same behaviour
|
|
as if the recommends can't be installed there is not much sense in checking
if it a new recommends or not
|
|
for the three different dependencies
|
|
|
|
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)
|
