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
Add Machine-ID to the first stanza, and copy Phased-Update-Percentage
to package stanzas.
This will be tested at a later state by the EDSP test case for
bug 1990586.
This fixes build on some architectures like mips
progress.cc:125:31: error: non-constant-expression cannot be narrowed from type 'std::chrono::duration<long long>::rep' (aka 'long long') to '__time_t' (aka 'long') in initializer list [-Wc++11-narrowing]
struct timeval NowTime = { Now_sec.count(), Now_usec.count() };
Signed-off-by: Khem Raj <raj.khem@gmail.com>
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.
A temporary filename is used as a workaround for bugs/missing features
in other software dealing with /dev/stdin, but nobody said I have to use
the exact same filename….
However in-tree builds are not generally recommended.
References:
aa4a4326d0fb0561efc4
Regression-Of: 701a501fb1
Reported-By: Lance Fredrickson <lancethepants@gmail.com>
Support for envvar NO_COLOR was added in 2.3.11, but with our own
options we can also be a tiny bit more sensible in not overriding
an explicit choice to disable colors.
References: 400a689556
The documentation currently does not specify whether `apt-get download`
verifies the authenticity of downloaded packages or not. The underlying
code does verify the authenticity of packages as usual and would fail if
the package signature is invalid. Therefore it makes sense to make this
guarantee explicit in the documentation, because without it
security-conscious users will likely want to recheck the signatures or
checksums manually which is not necessary in this case and just wastes
time.
First mark them for upgrade without autoInst, so we don't call
their "mark other binaries loop"; then call them again with it.
Without this change, each binary package would upgrade the next
one in the list, recursively.
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.
