| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves the functions of the PhasedUpgrader class into
various other classes so they can be publicly exposed.
This introduces three new functions:
pkgDepCache::PhasingApplied() tells you whether phasing should
be applied to the package.
pkgProblemResolver::KeepPhasedUpdates() keeps back updates that
have phasing applied.
pkgCache::VerIterator::IsSecurityUpdate() determines whether this
version contains security fixes.
|
| |
|
|
|
|
|
|
|
| |
previous ones
We only considered an update a security update if a previous update
is a security update but not the update in question itself.
LP: #2051181
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes an issue where phased updates gain new dependencies
and cause them to be installed despite themselves not being
installed.
In the cause of investigation, it turned out that we also need
to evaluate the candidate version at those early stage rather
than the install version (which is only valid *after* MarkInstall).
This does not fully resolve the problem: If an update pulls in
a phased update, depends are still being installed. Resolving
this while ensuring that phased updates cannot uninstall packages
requires us to do a minimization of changes by trying to keep
back each new install removal and then seeing if any dependency
is being broken by it. This is more complex and will happen
later.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the bug, mutter was kept back due to phasing and the new gnome-shell
depended on that, and was therefore kept back as well, however,
gnome-shell-common was not broken, and apt decided to continue upgrading
it by removing gnome-shell and the ubuntu desktop meta packages.
This is potentially a regression of LP#1990586 where we added keep
back calls to the start of the dist-upgrade to ensure that we do not
mark stuff for upgrade in the first place that depends on phasing
updates, however it was generally allowed by the resolver to also
do those removals.
To fix this, we need to resolve the update normally and then use
ResolveByKeepInternal to keep back any changes broken by held back
packages.
However, doing so breaks test-bug-591882-conkeror because ResolveByKeep
keeps back packages for broken Recommends as well, which is not
something we generally want to do in a dist-upgrade after we already
decided to upgrade it.
To circumvent that issue, extend the pkgProblemResolver to allow
a package to be policy broken, and mark all packages that already
were already going to be policy broken to be allowed to be that,
such that we don't try to undo their installs.
LP: #2025462
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By marking them at the end, we might make other decisions that
depend on the new phased updates, confusing the solver. Run the
marking at the start too.
The EDSP test file from Jeremy was modified to include Machine-ID
and Phased-Update-Percentage fields and then filtered to mostly
exclude packages irrelevant to the test case by running
grep-dctrl \( -FRequest "EDSP 0.5" -o -FInstalled yes \
-oFPhased-Update-Percentage 10 \) \
-a --not -FArchitecture i386
LP: #1990586
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a lot closer to the original implementation in update-manager,
but still has a couple of differences that might cause bugs:
- When checking whether a version is a security update, we only
check versions in between and not any later version. This happens
mostly because we do not know the suite, so we just check if there
is any version between the installed version and our target that
is a security update
- We only keep already installed packages, as we run before the
resolver. update-manager first runs the resolver, and then marks
for keep all packages that were upgraded or newly installed that
are phasing (afaict).
This approach has a significant caveat that if you have version 1
installed from a release pocket, version 2 is in security, and version
3 is phasing in updates, that it installs version 3 rather than 2
from security as the policy based implementation does.
It also means that apt install does not respect phasing and would
always install version 3 in such a scenario.
LP: #1979244
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it easier to see which headers includes what.
The changes were done by running
git grep -l '#\s*include' \
| grep -E '.(cc|h)$' \
| xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/'
To modify all include lines by adding a space, and then running
./git-clang-format.sh.
|
| |
|
|
|
| |
Including cacheiterators.h before pkgcache.h fails because
pkgcache.h depends on cacheiterators.h.
|
| |
|
|
|
|
|
|
| |
Most of them in (old) code comments. The two instances of user visible
string changes the po files of the manpages are fixed up as well.
Gbp-Dch: Ignore
Reported-By: spellintian
|
| |
|
|
|
| |
Create and log the EDSP(like) request even if we use the internal
resolver.
|
| |
|
|
|
|
|
|
|
| |
It wasn't noticeable before, but now with the (optional) logging it can
be observed that we decide in the internal path two times if an internal
or external solver should be used (and hence with logging, it is
attempted twice), so if we are in the internal path call the internal
resolver directly, which means those internal methods need to be public
– but we can hide them based on the symbol at least.
|
| |
|
|
|
| |
This allows to differentiate properly between 'apt-get upgrade', 'apt
upgrade' and 'apt full-upgrade'.
|
| |
|
|
|
|
|
|
|
| |
There is a good chance that the attempt will fail, but if a user
mentions certain packages explicitly on the commandline there is a
chance that this will consist of a broken system which is resolved
by upgrading more packages then just the mentioned.
This limitation was not effecting external resolvers.
|
| |
|
|
|
|
|
|
| |
We aren't and we will not be really compatible again with the previous
stable abi, so lets drop these markers (which never made it into a
released version) for good as they have outlived their intend already.
Git-Dch: Ignore
|
| |
|
|
|
|
|
|
| |
Adding a new parameter (with a default) is an ABI break, but you can
overload a method, which is "just" an API break for everyone doing
references to this method (aka: nobody).
Git-Dch: Ignore
|
| |
|
|
|
|
|
|
|
| |
For compatibility we use/provide and fill quiet some deprecated methods
and fields, which subsequently earns us a warning for using them. These
warnings therefore have to be disabled for these codeparts and that is
what this change does now in a slightly more elegant way.
Git-Dch: Ignore
|
| |
|
|
|
|
|
|
| |
The comment above their definition marks them already as such, so this
is only a formalisation of the deprecation and fixes the occurances we
have in our own code together with removing a magic number.
Git-Dch: Ignore
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we had a start and a done of the calculation printed by
higher-level code, but this got intermixed by progress reporting from an
external solver or the output of autoremove code…
The higherlevel code is now only responsible for instantiating a
progress object of its choosing (if it wants progress after all) and the
rest will be handled by the upgrade code. Either it is used to show the
progress of the external solver or the internal solver will give some
hints about its overall progress. The later isn't really a proper
progress as it will jump forward after each substep, but that is at
least a bit better than before without any progress indication.
Fixes also the 'strange' non-display of this progress line in -q=1, while
all others are shown, which is reflected by all testcase changes.
|
| | |
|
| |
|
|
|
|
|
|
| |
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)
|
| | |
|
| | |
|
|
|
The upgrade releated code is moved into upgrade.{cc,h} and
all pkg*Upgrade* prototypes are included in algorihms.h to
avoid breaking API (unless build with APT_9_CLEANER_HEADERS).
|
