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
When iterating over I's dependencies (which are called Pkg), we
accidentally checked if I was Protected() instead of Pkg when deciding
whether Pkg can be kept back.
LP: #1990684
The command line is evaluated in two steps: First all packages given
are marked for install and as a second step the resolver is started on
all of them in turn to get their dependencies installed.
This is done so a user can provide a non-default choice on the command
line and have it respected regardless of where on the command line it
appears.
On the other hand, the order in which dependencies are resolved can
matter, so instead of using a "random" order, we now do this in the
order given on the command line, so if you e.g. have a meta package
pulling in non-default choices and mention it first the choices are
respected predictably instead of depending on first appearance of the
package name while creating the binary cache.
I might have "broken" this more than a decade ago while introducing the
reworked command line parsing for Multi-Arch, which also brought in the
split into the two steps mentioned above which was the far more
impactful 'respect user choice' change. This one should hardly matter in
practice, but as the tests show, order can have surprising side effects.
Schedule all other binaries in the source package for upgrade if
the candidate version belongs to the same source version as the
package we are upgrading.
This will significantly reduce the risk of partial upgrades and
should make life a lot easier.
Currently the solver handles cases where a Breaks b (<< 1) and
if we install that a, upgrades b. However, where b Depends a (= 1),
b was removed again.
This addresses the problem by iterating over installed reverse
dependencies of upgrades and upgrading them so that both cases
work roughly similarly.
LP: #1974196
If a package is already pinned to a negative value, we should not
override this with a positive 1. This causes packages to be installable
that were pinned to -1, which is not intended.
For this, implement phasing as a ceiling of 1 for the pin instead
of a fixed 1 value. An alternative would have been to fix it to
NEVER_PIN, but that would mean entirely NEW packages would not be
installable while phasing which is not the intention either.
LP: #1978125
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
Some of our headers use APT_COMPILING_APT trickery to avoid exposing too
broadly details we don't want external clients to know and make use of.
The flip-side is that this can lead to different compilation units
seeing different definitions if they aren't all using the same config.
We use 'stty sane' to combat against stepped output and co caused by
(especially) failed tests, but it does so many things that it
occasionally fails to reset some bits in the parallel interaction we
have with it which fails the tests without a real problem in apt…
Ideally we would be better at stitching the output together, but for the
time being lets ignore these failures instead to stabilize the tests.
Building the library just so we can build the helpers against it is not
only wasteful but as we are supposed to test the system we can use that
as an additional simple smoke test before the real testing starts.
The kernel autoremoval algorithm was written to accomodate
for Ubuntu's boot partition sizing, which was written to
accomodate 3 kernels - 2 installed ones + a new one being
unpacked.
It seems that when the algorithm was designed, it was overlooked
that it actually kept 3 kernels.
LP: #1968154
We abstract hashes a fair bit to be able to add new ones eventually,
which lead us to building the field names on the fly. We can do better
through by keeping a central place for these names, too, which even
helps in reducing code as we don't need the MD5 → Files dance anymore.
The dependency relation fields old names were deprecated in 1995
as the new ones were introduced. That seems barely long enough now
as a transition period.
The previous regime of the file was to sort it on insert, but that
changes the values in the generated enum, which is fine as long as we
only use it in libapt itself, but breaks on other users.
The header was always intended to be private to apt itself, so we just
document this here now and lay the ground work to have the file in the
future only appended to, so that it remains sufficiently ABI stable that
we can use it outside the library in our apt tools.
We also remove some fields apt is unlikely to need or only uses in
certain cases outside of any (speed) critical path to have enough room
to add more fields soon as currently we are limited to 128 fields max
and it would be sad if we use up that allowance entirely already.
The hack is 7 years by now, so in an attempt to make that slightly
cleaner lets move this to proper variables that can be assigned via
an extra-environment file sources by the framework rather than relying
on my user name and locate in public.
Gbp-Dch: Ignore
apt/test/interactive-helper/aptwebserver.cc: In function ‘std::string HTMLEncode(std::string)’:
error: variable ‘constexpr const std::array<std::array<const char*, 2>, 6> htmlencode’ has initializer but incomplete type
Reported-By: Helmut Grohne on IRC
Julian Andres Klode
Julian Andres Klode
Khem Raj
David Kalnischkies