Age | Commit message (Collapse) | Author |
|
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)
|
|
* apt-pkg/depcache.cc:
- Really release action groups only once (Closes: #622744)
* apt-pkg/acquire-item.cc:
- Only try to rename existing Release files (Closes: #622912)
|
|
|
|
- really include 'rc' packages in the delete count by fixing a
typo which exists since 1999 in the source… (LP: #761175)
|
|
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.
|
|
|
|
- remove pseudo handling leftover from SetReInstall
|
|
seperate IsModeChangeOk which checks sanity and dpkg holds
|
|
Multi-Arch; instead, Arch: all packages only satisfy dependencies for
the native arch, except where the Arch: all package is declared
Multi-Arch: foreign. (Closes: #613584)
This has the sideeffect that arch:all packages internally show up as
coming from the native arch - so packages with the architecture "all"
doesn't exist any longer in the pkgcache
|
|
- party revert fix in 0.8.11.2 which marked all packages as manual
installed if the FromUser bit is set in the MarkInstall call.
The default for this bit is true and aptitude depends on the old
behavior so the package is only marked as manual if its not marked
("old" behavior) or if automatic installation is enabled - which
aptitude disables always (see also #613775)
|
|
- mark a package which was requested to be installed on commandline
always as manual regardless if it is already marked or not as the
marker could be lost later by the removal of rdepends (Closes: #612557)
|