| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Apologies.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dpkg (>= 1.20.3) has better support for its own DPKG_ROOT resulting in
architectures for the root being reported rather than the host system.
Sadly the hookscript from pkg-config is not prepared for this resulting
in our `dpkg --add-architecture` calls failing in the hook after dpkg
has successfully added the architecture internally. The failure
triggered fallback handling in the tests to work with an older version
of dpkg with a different multi-arch implementation.
So instead of doing the fallback, we ignore the failure if it seems like
pkg-config-dpkghook is involved only producing a bunch of warnings
to hint at this problem, but otherwise make the tests work again as it
is a post-invoke script.
References: #824774
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test runs ls on the opened fds and greps the result for 'root root'
which is how ls (<= 8.30) used to report user and group for these. Now
that Debian contains 8.32 it reports user and group of the process
owning them (supposedly). grepping for both unbreaks the test.
lr-x------ 1 root root 64 Jul 7 19:07 0 -> 'pipe:[10458045]'
lrwx------ 1 root root 64 Jul 7 19:07 1 -> /dev/pts/12
lrwx------ 1 root root 64 Jul 7 19:07 2 -> /dev/pts/12
lr-x------ 1 root root 64 Jul 7 19:07 3 -> /proc/1266484/fd
vs (assuming user:group is david:david)
lr-x------ 1 david david 64 Jul 7 19:07 0 -> 'pipe:[10458045]'
lrwx------ 1 david david 64 Jul 7 19:07 1 -> /dev/pts/12
lrwx------ 1 david david 64 Jul 7 19:07 2 -> /dev/pts/12
lr-x------ 1 david david 64 Jul 7 19:07 3 -> /proc/1266484/fd
|
| |
|
|
|
|
|
|
|
|
|
| |
We were traditionally adding points for some dependency types to the
real package, but we should also do it for providers of that package to
help the resolver especially if the real package is for some reason not
tagged for removal yet/anymore.
While at it we ensure that the points are only attributed once for each
package as especially with versioned provides a package can nowadays
provide another many times and would hence acquire a lot of points.
|
| |
|
|
|
|
|
|
| |
If the package providing the given solution is tagged already for
removal (or at least for "not installing") we can ignore this solution
as a possibility as it is not one, which means we can avoid exploring
the option and potentially forward the protected flag further if that
helps in reducing the possibilities to a single one.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Marking a package for removal is fine if we know that we have to remove
that package, but if we are in an alternative branch we might not go
this route in the end and hence have a package pointlessly marked for
removal which isn't questioned later on.
We check if we are allowed to remove that package to avoid working on
the positive dependencies if not, but we mark them for removal only
after all the other dependencies are successfully resolved.
In an ideal world we would let the problemResolver do its job on them,
but the resolver might decide against doing the removal exploring
another option like the next alternative, which might be a good idea,
but is not the behaviour we had before, so that is the best we can do
for now without changing the resolver drastically.
|
| |
|
|
| |
This will be mapped to Important for the time being.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
M-A:foreign causes Provides to apply to all architectures and as we
wanted to avoid resolver changes for M-A those are done by explicitly
creating these provides instead of forcing the resolvers to learn about
this. The EDSP is a different beast though & we don't need this trick
here especially as it leads to needless (but harmless) duplication.
No sort+unique is done to avoid changing order (not that it should
matter, but just to be sure), but the sets should be small enough to not
make a huge difference either way.
|
| |
|
|
|
|
|
|
| |
We usually tell EDSP solvers only about architectures we are configured
to treat as native/foreign, but the system could have packages from
other architectures installed (even if very unlikely) which could
influence the solution (e.g. requiring a removal) so we make sure to
tell them.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If package is installed via an explicitly given deb file we store the
filename as a provides, so that the frontend can request the filename
and get the usual "Selected foo instead of foo.deb" message.
We do not need to trouble the EDSP solvers with that though as these
provides are not valid in various ways and we have already solved the
link between commandline and package (and version) for them.
Closes: #962741
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
While we process the possible solutions we might modify other solutions
like discarding their candidates and such, so that then we reach them
they might no longer be proper candidates. We also try to drop
duplicates early on to avoid the simple cases of these which
test-explore-or-groups-in-markinstall triggers via its explicit
duplication but could also come via multiple provides.
It only worked previously as were ignoring current versions which
usually is okay expect if they are marked for removal and we want to
reinstate them so the ProblemResolver can decide which one later on.
|
| |
|
|
|
|
|
|
|
| |
For protected packages the "Fixing" done via KillList in the
ProblemResolver will usually not happen as the state change is not
allowed, so the debug message is just confusing and the resolver is
needlessly looping here (which might push it over the edge), so if we
didn't do our thing successfully here we short-circuit a bit to help the
next iteration come to a solution.
|
| |
|
|
|
|
|
|
|
|
| |
The pkgProblemResolver incorrectly skips protected packages while
considering packages for removal, which was always wrong but is now a
lot more visible as (potentially) far more packages are considered
protected in their state.
Note that the testcase shows that we need more changes to make this
proper.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No sensible file should include these, but even insensible files do not
gain unfair advantages with it as this parser does not deal with
security critical files before they haven't passed other checks like
signatures or hashsums.
The problem is that the parser accepts and parses empty tag names
correctly, but does not store the data parsed which will effect later
passes over the data resulting e.g. in the following tag containing
the name and value of the previous (empty) tag, its own tagname and its
own value or a crash due to an attempt to access invalid memory
depending on who passes over the data and what is done with it.
This commit fixes both, the incidient of the crash reported by
Anatoly Trosinenko who reproduced it via apt-sortpkgs:
| $ cat /tmp/Packages-null
| 0:
| PACKAGE:0
|
| :
| PACKAGE:
|
| PACKAGE::
| $ apt-sortpkgs /tmp/Packages-null
and the deeper parsing issue shown by the included testcase.
Reported-By: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
References: 8710a36a01c0cb1648926792c2ad05185535558e
|
| |
|
|
|
|
| |
Remove all code scheduled to be removed after 5.90, and fix
files to include files they previously got from hashes.h
including more headers.
|
| |
|
|
|
|
|
|
| |
This experiment did not turn out sensibly, as some servers do not
accept credentials when none are expected and fail, so you cannot
mirror such a repository.
This reverts commit c2b9b0489538fed4770515bd8853a960b13a2618.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
we have to stop parsing on space so that things like ~ramd64 | ~rall
work correctly.
aptitude does not stop parsing on ?, but we'll do as it gets very
confusing otherwise if you write stuff like ~ramd64?name(foo), and
it resolves to ?and(?architecture(amd64?name), (foo))...
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the syntax from approximately
expr = unary
unary = '!'? primary
primary = pattern | short-pattern | word | quoted-word
pattern = '?' name [ '(' expr [',' expr]* ')' ]
short-pattern = ~ name | ~name expr
to:
primary = pattern | short-pattern
argument = word | quoted-word | expr
pattern = '?' name [ '(' argument [',' argument]* ')' ]
short-pattern = ~ name | ~name argument
|
| | |
|
| |
|
|
|
|
| |
Also make pattern detector in cacheset and private's list accept
such patterns. We probably should just try to parse and see if it
is a (start of a) pattern.
|
| |
|
|
|
|
|
|
|
|
| |
Since we append a concrete kernel version to each pattern, and then
anchor the pattern, let's just pick any package starting with a
kernel name (linux-, kfreebsd-, gnumach-), and not worry about
linux-headers, linux-tools, etc specifically, as they'll be caught
by the generic pattern.
LP: #1607845
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
APT 1.9.6 introduced empty groups by making use of groups to
deduplicate package names. This is not normally a problem, but
here we assumed that every group has at least one package.
This caused a problem because automake was providing automake-1.16
while having the source package automake-1.16. So we found the
automake-1.16 group, iterated over its empty package list, trying
to store the provides (which hence never happened).
LP: #1859952
|
| |\
| |
| |
| |
| | |
apt(8): Disable regular expressions and fnmatch
See merge request apt-team/apt!95
|
