| Age | Commit message (Collapse) | Author |
|---|
|
Also translating two related strings along the way.
References: https://github.com/Debian/apt/pull/107
|
|
apt marks packages coming from the commandline among others
as protected to ensure the various resolver parts do not fiddle
with the state of these packages. aptitude (and potentially others)
do not so the state is modified (to a Keep which for uninstalled means
it is not going to be installed) due to being uninstallable before
the call fails – basically reverting at least some state changes the
call made before it realized it has to fail, which is usually a good
idea, except if users expect you to not do it.
They do set the FromUser option though which has beside controlling
autobit also gained the notion of "the user is always right" over time
and can be used for this one here as well preventing the state revert.
References: 0de399391372450d0162b5a09bfca554b2d27c3d
Reported-By: Jessica Clarke <jrtc27@debian.org> on IRC
|
|
|
|
We did not merge nl with the template when we updated it,
hence we have quite a bit of churn in that commit and this
one.
|
|
Reinstate * wildcards
See merge request apt-team/apt!118
|
|
Previously (and still in cacheset), patterns where only allowed to
start with ? or ~, which ignores the fact that a pattern might just
as well start with a negation, such a !~nfoo.
Also, we ignored the --regex flag if it looked like this, which
was somewhat bad.
Let's change this all:
* If --regex is given, arguments are always interpreted as regex
* If it is a valid package wildcard (name or * characters), then
it will be interpreted as a wildcard - this set of characters is
free from meaningful overlap with patterns.
* Otherwise, the argument is interpreted as a pattern.
For a future version, we need to adapt parsing for cacheset and
list to use a common parser, to avoid differences in their
interpretation. Likely, this code will go into the pattern parser,
such that it generates a pattern given a valid fnmatch argument
for example.
|
|
Reinstate * wildcards as they are safe to use, but do not allow any
other special characters such as ? or [].
Notably, ? would overlap with patterns, and [] might overlap with
future pattern extensions (alternative bracketing style), it's also
hard to explain.
Closes: #953531
LP: #1872200
|
|
Refactor MarkInstall fixing various or-group handling issues
See merge request apt-team/apt!117
|
|
Strange things happen if while resolving the dependencies of a package
said dependencies want to remove the package. The allow-scores test e.g.
removed the preferred alternative in favor of the last one now that they
were exclusive. In our or-group for Recommends we would "just" not
statisfy the Recommends and for Depends we engage the ProblemResolver…
|
|
In normal upgrade scenarios this is no problem as the orgroup member
will be marked for upgrade already, but on a not fully upgraded system
(or while you operate on a different target release) we would go with our
usual "first come first serve" approach which might lead us to install
another provider who comes earlier – bad if the providers conflict.
|
|
If a package is protected and has a dependency satisfied only by a single
package (or conflicts with a package) this package must be part of the
solution and so we can help later actions not exploring dead ends by
propagating the protected flag to these "pseudo-protected" packages.
An (obscure) bug this can help prevent (to some extend) is shown in
test-apt-never-markauto-sections by not causing irreversible autobit
transfers.
As a sideeffect it seems also to help our crude ShowBroken to display
slightly more helpful messages involving the packages which are actually
in conflict.
|
|
MarkDelete is not recursive as MarkInstall is and we can not conflict
with ourselves anyhow, so we can move the unavoidable deletes before
changing the state of the package in question avoiding the need for the
state update in case of conflicts we can not deal with (e.g. the package
conflicts with an explicit user request).
|
|
Should be easier to move the code bits around then and it helps in
documenting a bit what the blocks do and how they interact (or not).
|
|
We do pretty much the same in IsInstallOk, but here we have already set
the state, so we have to unroll the state as well to sort-of replicate
the state we were in before this MarkInstall failed.
|
|
This fixes no bugs per se, but the idea is to delay more costly changes
and check easier things first. It e.g. inhibits the moving of the
autobit until we are sure that this MarkInstall call isn't going to
fail (e.g. because a dependency isn't satisfiable).
|
|
MarkInstall only looks at the first alternative in an or-group which has
a fighting chance of being satisfiable (= the package itself satisfies
the dependency, if it is installable itself is not considered).
This is "hidden" for Depends by the problem resolver who will try
another member of the or-group later, but Recommends are not a problem
for it, so for them the alternatives are never further explored.
Exploring the or-group in MarkInstall seems like the better choice for
both types as that frees the problem resolver to deal with the hard
things like package conflicts.
|
|
We reseted the candidate for installed packages back to the version
which is installed if one of the (critical) dependencies of it is not
statisfiable, but we can do the same for non-installed packages by
discarding the candidate which beside slightly helping the resolver also
improves error messages generated by apt as a sideeffect.
|
|
Reported-By: gcc -Wuseless-cast
Gbp-Dch: Ignore
|
|
Reported-By: clangd
Gbp-Dch: Ignore
|
|
Closes: #956313
|
|
|
|
ubuntu: http: Add non-interactive to user agent if run by systemd
See merge request apt-team/apt!114
|
|
Include that apt is being run from a service in the user
agent, so traffic can be analysed for interactive vs
non-interactive use, and prioritised accordingly.
It looks like this now:
User-Agent: Debian APT-HTTP/1.3 (2.0.1) non-interactive
A previous version included the full service names, but this
raised some privacy concerns.
LP: #1825000
|
|
Recent GnuTLS 3.6.11 -> 3.6.13 update in Ubuntu broke our
test certificate, it's signed with SHA1. Regenerate with
SHA2.
openssl req -newkey rsa:2048 -x509 -sha256 -days 36500 -nodes -out apt.crt -keyout apt.key -subj "/CN=localhost/O=APT Testcases GmbH/ST=Some-State/C=DE"
cat apt.key apt.crt > test/integration/apt.pem
|
|
|
|
|
|
Closes: #955412
|
|
Closes: #955505
|
|
Closes: #955023
|
|
|
|
Add color highlighting to E:/W:/N: prefixes
See merge request apt-team/apt!112
|
|
This caused unbound error list growth, because each time
we dumped an error, the calls to _config->FindB() inside
operator << would add 3 new errors of the form:
W: Using unknown config option »apt::color« of type BOOL
Hence we are dumping an infinite list of errors, and eventually
that list will exceed available memory.
|
|
This matches the definitions used by dpkg.
Closes: #953527
|
|
apt-helper: Add analyze-pattern helper
See merge request apt-team/apt!113
|
|
Closes: #953804
|
|
While merging apt-pkg and apt-inst libraries the codepath of handling
deb files in apt-pkg was adapted to use the 'old' code from apt-inst
instead of fork&exec of dpkg-deb -I. The information we get this way
forms the main part of the package stanza, but we add a few
semi-optional fields to the stanza to make it look and work more
like a stanza we got from a repository.
Just be careful with the area where these two parts touch as if,
hypothetically, we would stip all newlines around the parts,
but forget to add a newline between them later, the two lines around
the merge would stick a bit too close together forming one which could
result in fun parsing errors if this merged line was previously e.g. a
well-formed Depends line and has now extra fluff attached.
This codepath has a history with too many newlines (#802553) though,
so how likely is it really that it will some day lack one you may ask.
References: 6089a4b17c61ef30b2efc00e270b0907f51f352a
|
|
The analyze-pattern helper parses a pattern and then renders
the parsed pattern, allowing you to analyze how the parser
interpreted the string.
This can be useful to analyse (yes, analyse-pattern also works)
why a pattern is different from aptitude or why it does not
work as expected.
It can also be used to check if apt has pattern support, although
that will miss out on the version shipped in eoan, but who really
cares about that longer term anyway?
|
|
Extract the code, and reformat it with clang-format so we can
modify it.
|
|
Packages from third-party sources do not always follow the established
patterns of more properly maintained archives. In that case it was a
driver package for a scanner&printer device which has only a minimum of
info attached, but also minimal non-installed packages do not include
sections, so we really shouldn't assume their availability.
|
|
|
|
Pu/improve locking msgs
See merge request apt-team/apt!111
|
|
Showing a percentage for a timeout is pretty non-standard. Rework the
progress class so it can show an absolute progress (currently hardcoded
to use seconds as a unit). If there is a timeout (aka if it's not the
maximum long long unsigned -1llu), then show the timeout, otherwise
just count up seconds, e.g.
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 33842 (apt)... 1/120s
or
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 33842 (apt)... 1s
Also improve the error message to use "Waiting for cache lock: %s" instead of "... (%s)", as having
multiple sentences inside parenthesis is super weird, as is having two closing parens.
We pass the information via _config, as that's reasonably easy and avoids
ABI hackage. It also provides an interesting debugging tool for other
kinds of progress.
|
|
This improves the locking message, getting rid of useless details. If
we have a process holding the lock, we got that because the lock is
being hold by it, so there's no point telling the people the reason
for not getting the lock is the EAGAIN error and displaying its
strerrror().
|
|
|
|
|
|
|
|
|
|
Pu/wait lock
See merge request apt-team/apt!109
|
|
apt-pkg: default visibility to hidden
See merge request apt-team/apt!108
|
|
This is a rework of !6 with additional stuff for the frontend
lock, so we can lock the frontend lock and then keep looping
over dpkg lock.
|
