| Age | Commit message (Collapse) | Author |
|---|
|
It looks like hack and therefore I wanted this to be a very isolated
commit so we can find it & revert it easily if need be, but for now it
seems to work.
The idea is that Status is telling us how the candidate is in relation
to the current installed version which is used to figure out if a
package is "kept back" by the algorithm or not, but by discarding the
candidate version we loose this information.
Ideally we would keep better tabs on what we do to a package and why,
but for now that seems okayish. It will cause the wrong version to be
displayed though as if the package is installed the installed version
becomes the candidate and hence (installed => installed) is displayed.
|
|
If we have a negative dependency to deal with we prefer to install an
upgrade rather than remove the current version. That is why we split the
method rather explicitly in two in 57df273 but there is a case we didn't
react to: If we have seen the candidate before as a "satisfier" of this
negative dependency there is no point in trying to upgrade to it later
on. We keep that info by candidate discard if we can, but even if we
can't we can at least keep that info around locally.
This "fixes" (or would hide) the problem described in 04a020d as well as
you don't have to discard installations you never make.
|
|
For a (partially) installed package like the one MarkInstall operates on
at the moment we want to discard the candidate from, we have to first
remove the package from the internal state keeping to have proper broken
counts and such and only then reset the candidate version which is a
trivial operation in comparison.
Take a look at the testcase: Now, what is the problem? Correct,
git:i386. Didn't see that coming, right? It is M-A:foreign so apt tries
to switch the architecture of git here (which is pointless, it knows
that this won't work, but lets fix that in another commit) will
eventually realize that it can't install it and wants to discard the
candidate of git:i386 first removing the broken indication like it
should, removing the install flag and then reapplies the broken
indication: Expect it doesn't as it wants to do that over the candidate
version which the package no longer had so seemingly nothing is broken.
It is a bit of a hairball to figure out which commit it is exactly that
is wrong here as they are all influencing each other a bit, but >= 2.1
is an acceptable ballpark. Bisect says 57df273 but that is mostly a lie.
Closes: #961266
|
|
|
|
References: dcdfb4723a9969b443d1c823d735e192c731df69
|
|
|
|
When we could not find a translated description, we were
pushing V.TranslatedDescription() to the vector, but that
one might not have been good either.
Add the check so we don't crash later when trying to access
it.
LP: #1877987
|
|
Turns out that pkgDepCache and pkgProblemResolver maintain two (semi)
independent sets of protected flags – except that a package if marked
protected in the pkgProblemResolver is automatically also marked in the
pkgDepCache as protected. This way the pkgProblemResolver will have as
protected only the direct user requests while pkgDepCache will
(hopefully) propagate the flag to unavoidable dependencies of these
requests nowadays. The pkgProblemResolver was only checking his own
protected flag though and based on that calls our Mark* methods usually
without checking return, leading to it believing it could e.g. remove
packages it actually can't remove as pkgDepCache will not allow it as it
is marked as protected there. Teaching it to check for the flag in the
pkgDepCache instead avoids it believing in the wrong things eventually
giving up.
The scoring is keeping the behaviour of adding the large score boost
only for the direct user requests though as there is no telling which
other sideeffects this might have if too many packages get too many
points from the get-go.
Second part of fixing #960705, now with pkgProblemResolver output which
looks more like the whole class of problem is resolved rather than a
teeny tiny edgecase it was before.
|
|
The previous commit deals with negative, now we add the positive side of
things as well which makes this a recursive endevour. As we can push the
protected flag forward only if a single solution for a dependency exists
it is easy for trees to not get it, so if resolving becomes difficult it
won't help at all.
|
|
If we propagate protected e.g. due to a user request we should also act
upon (at the moment) satisfied negative dependencies so that the
resolver knows that installing this package later is not an option.
That the problem resolver is trying bad solutions is a bug by
itself which existed before and after and should be worked on.
Closes: #960705
|
|
For positive dependencies this isn't giving much as the dependency
should already be satisfied by such a provider if its protectiveness
would help, but it doesn't hurt to check them first and for negative
dependencies it means that we check those first which are the most
likely to fail to be removed – which is a good idea.
|
|
The important change is adding IsIgnoreable() as it will deal with
self-conflicts and such, but while we are at it lets sprinkle in some
refactoring.
|
|
Reducing the scope of these helpers might allow us to move them
elsewhere and share them or it is a rather pointless exercise,
we will see where it leads us to later on.
Gbp-Dch: Ignore
|
|
We exit early from installing dependencies of a package only if it is
not a user request to avoid polluting the state with installs which
might not be needed (or detrimental even) for alternative choices.
We do continue with installing dependencies though if it is a user
request as it will improve error reporting for apt and can even help
aptitude not hang itself so much as we trim the problem space down for
its resolver dealing with all the easy things.
Similar things can be said about the testcase I have short-circuit
previously… keep going test, do what you should do to report errors!
|
|
The variable this is read to is named Junk and that it is for usecases
like apt-ftparchive which just looks at the items metadata, so instead
of performing this hunked read for data nobody will process we just tell
our FileFd to skip ahead (Internally it might still loop over the data
depending on which compressor is involved).
|
|
With FileFd::Write we already have a helper for this situation we can
just make use of here instead of hoping for the best or rolling our own
solution here.
|
|
Our testcases had their own implementation of GetTempFile with the
feature of a temporary file with a choosen suffix. Merging this into
GetTempFile lets us drop this duplicate and hence test more our code
rather than testing our helpers for test implementation.
And then hashsums_test had another implementation… and extracttar wasn't
even trying to use a real tempfile… one GetTempFile to rule them all!
That also ensures that these tempfiles are created in a temporary
directory rather than the current directory which is a nice touch and
tries a little harder to clean up those tempfiles.
|
|
Not all filesystems implement this feature in all versions of Linux,
so this open call can fail & we have to fallback to our old method.
|
|
|
|
|
|
|
|
(CVE-2020-3810)
When normalizing ar member names by removing trailing whitespace
and slashes, an out-out-bound read can be caused if the ar member
name consists only of such characters, because the code did not
stop at 0, but would wrap around and continue reading from the
stack, without any limit.
Add a check to abort if we reached the first character in the
name, effectively rejecting the use of names consisting just
of slashes and spaces.
Furthermore, certain error cases in arfile.cc and extracttar.cc have
included member names in the output that were not checked at all and
might hence not be nul terminated, leading to further out of bound reads.
Fixes Debian/apt#111
LP: #1878177
|
|
Closes: #960186
|
|
|
|
References: https://github.com/mquinson/po4a/commit/329f472a378d42c7a33e8110e5091be61480a0fc
|
|
Upstream says it had no effect before, so it seems safe to adapt.
References: https://github.com/mquinson/po4a/commit/ac1e97305b6073ed87fa8cf0a2e32f9b1255d0f1
|
|
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
|
