| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor the various Install requests into a single one and move
some stuff around, this should be a bit easier to maintain and
we don't repeat ourselves all the time.
This accidentally uncovered some bugs in the code, that get fixed
by this:
- The UpgradeManual and InstallManual groups did not work correctly,
Essential packages were Install and others were Upgrade.
- Automatically installed packages falsely got promoted to the
manual groups as they got promoted into the manual code path,
whenever we ran without allowing their removal.
- The combination of --mark-auto --auto-remove now works correctly
We previously skipped the installation of automatically installed
packages when we did autoremoval, but we did not consider if the
action was protected, that is specified on the command-line.
Now we do not autoremove protected actions, and have added a test
case for it.
- The AllowRemoveManual option no longer is applied if removals are
generally denied.
Closes: #1071519
|
| |
|
|
|
|
| |
We should set the Mark/Garbage flags for all packages so we don't
end up in an inconsistent state, so reset the flags for each package
before evaluating further.
|
| |
|
|
|
|
|
|
|
|
| |
As part of the refactoring, we allowed the code to work on unimportant
dependencies as we needed to promote Suggests to Depends if they are
currently satisfied.
However, Replaces and Enhances were not considered properly and both
are not negative dependencies so they were accidentally promoted to
Depends too if they were currently satisfied.
|
| |\
| |
| |
| |
| | |
edsp: Parse source version from the Source-Version field
See merge request apt-team/apt!354
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
EDSP uses the Source-Version field instead of storing the source
version in the Source field with the package name, adjust our
parser accordingly.
Use the override in the edspLikeListParser to do so rather than
dumb this into the correct place in the debListParser.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This has two aspects:
1. For a dependency A | B | C we order the obsolete packages last,
that is, if A is obsolete, this gets reordered to B | C | A,
such that we try to pick non-obsolete packages first to ease
upgrade calculation.
2. When comparing two dependencies, we order dependencies into three
groups: First we satisfy dependencies mentioning only non-installed
(NEW) packages, then we satisfy "normal" dependencies, and finally
we satisfy any dependencies mentioning obsolete packages.
This means for example if you have obsolete libfoo1 and a new
libfoo1t64, that we will see Depends: libfoo1t64 before any
Depends: libfoo1 (which may expand to libfoo1 | libfoo1t64),
so we effectively will have selected "replacement" packages
this way already before getting to older packages where we
would have to choose between the obsolete package and its
replacement.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Comparing the size of work items is not strictly needed; we check
if items have a single or no solution and propagate them early on,
but it doesn't matter much if we solve A|B or C|D|E first. This
will allow us to get rid of all the resizing business later on,
and switch to using literal watching where we only watch one of
the literals on the right hand side.
Likewise, the upgrade case mattered initially in testing, but seems
to have resolved itself.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Our backtracking is chronological, so we will first
try alternative choices or skip optional items in
later groups.
So installing manually installed packages before automatically
installed ones allows manually installed packages to remove
automatically installed packages easily. If we did automatic
packages first, we'd keep back upgrades for manual packages
or change choices for their dependencies, or would have to
backtrack harder to get back to the right decision level.
That's silly.
Ordering automatically installed packages last also allows
us to calculate autoremovable packages. Since we will have
installed all dependencies from manually installed packages
by the point where we get to automatically installed packages,
everything that will be installed in those Auto groups is
inherently garbage.
|
| |/
|
|
|
|
|
|
|
| |
We use a union here, but we don't know if we last stored a pointer,
so let's just reject clearly non-sizes. Generally this will work fine
-- you will not have enough choices in a dependency that you can
construct a valid pointer to a Version*, especially given that
any Version * > sizeof(pkgCache::Header) already, given it is
in the cache.
|
| |
|
|
|
|
|
|
|
| |
We also need to issue a MarkDelete() if the package is marked for
installation currently but should not be, not only if it did not
have a previous version.
This fixes the final test in test-multiarch-barbarian, the others
only needed adjustments to mark all packages as automatic.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When restoring previously solved items, we try to restore items
that have become unsolved again by skipping items that have a
solved solution.
Well at least we thought we did, but we accidentally had a "not"
in there that inverted the meaning, hence we lost work items on
backtracking.
This mostly did not seem to have caused any issues, I stumbled
over it while trying to add `autoremove` listings to `upgrade`,
but fixing it also fixes:
test-ubuntu-bug-1130419-prefer-installed-ma-same-siblings
This used to say "E: Broken packages", meaning the solver lost
a non-optional install request and the 2nd stage solver caught
an incomplete solution.
Also test-bug-735967-lib32-to-i386-unavailable restores the legacy
solver behavior, so win win?
|
| |
|
|
|
|
|
|
|
|
| |
While it seems that libstdc++ is using stable_sort for sort,
we should make this explicit: We don't want items in our queues
to move ahead of earlier items of the same priority.
i.e. consider dependencies, they are grouped by package, we don't
want the sort algorithm to move B=2 ahead if A|B (which expands to
A=2|A=1|B=2|B=1).
|
| |
|
|
|
|
|
| |
This somewhat improves reliability of not breaking Recommends, e.g.
if the Recommends gets tightened. One test case enabled by this now
is the test-resolver-provider-exchange, which with a simple change
to allow removal of automatically installed packages works now.
|
| |
|
|
|
|
| |
As per the test-suggests-promoted-to-recommends test. This is still
a bit messy as we ignore alternative choices and only check the last
one, but um seems useful?
|
| |
|
|
|
|
|
|
|
|
| |
This fixes --no-strict-pinning attempting to upgrade all the versions
on the system. Adjust the upgrade test case accordingly:
1) no-strict-pinning pulls in systemd despite it being pinned down due
to a dependenc (this was true before this fix)
2) no-strict-pinning does not pull in the upgrade-simple because nothing
depends on it (this is what the test fixes)
|
| |
|
|
|
|
| |
This is mostly going to be useful for the test suite for now,
implement a function there to set it up so we can use it to
improve test suite correctness.
|
| |
|
|
|
| |
Ignore the Solving dependencies... line in the testing framework
for compatibility with the existing test cases.
|
| |
|
|
|
|
|
| |
When -o Dir::Cache::pkgcache or -o Dir::Cache is set to /dev/null
we accidentally changed its mode to 0666; which is certainly not
intended. Avoid this issue by exiting the function early if the
file specified is /dev/null.
|
| |
|
|
|
|
|
|
| |
Another instance of our parser written for sane clean input, but
nowadays used also for user-provided input which can contain very many
strange formatting and especially white spaces all over the place.
Closes: #1071219
|
| |
|
|
|
|
|
|
|
|
|
| |
The test is actually documenting another bug hidden a bit by this one as
we do not need to install a NEW package in this situation as the upgrade
needing it was kept back, but it was protected from considering it to
be autoremoveable as all providers tend to be considered protected, but
by limiting us to installed providers if we have some we can drag those
new packages out of hiding.
Now, we "just" have to get right of the NEW package in a next step.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a simple backtracking brute-force solver with heurisitcs,
this initial version has the following known gaps:
- Errors are not kept from branches, the error reporting after
backtracking isn't particularly useful.
- We cannot show automatically removed packages
- We cannot replace packages with others
- We do not have conflict-driven clause learning yet
Untested:
- Multi-arch
This solver is fundamentally different in key aspects:
- It solves smaller dependency groups before larger ones, leading
us to avoid installing A in A|B if B is installed more often and
more consistently.
- It only keeps the automatic packages reachable via the strongest
path. Currently it only implements autoremoval, but not display
of autoremoval as we simply enqueue all automatically installed
packages at the end when not doing automatic removal.
This will need some translation where we Solve() first, and then
Solve() again with the automatically installed packages added such
that we can mark them as Garbage for display purposes.
- It does not remove manually installed packages.
Hook the solver in via the EDSP framework, this allows us to achieve
easy initial integration without lots of issues.
A lot of this work was planned and executed in my free time and then
some leaked into work time I suppose.
Implementation notes:
- Restore the full backlog of items
The annoying thing is that we record only when an item was enqueued
and not the level at which it was installed, so when going back a
decision level we might have to reinstall packages that were queued
at an earlier decision level because they were only installed at a
later decision level.
- When picking one version, reject the others
- Propagate conflicts up to reverse dependencies
This will recursively mark every reverse dependency that can
no longer be satisfied as MUSTNOT.
Also make sure to recursively call Reject(Ver) from Reject(Pkg)
to make sure we trigger the Rejections there.
This means we now end up having Recursion in the algorithm. An
alternative approach would be to push *reject* items to the heap
and then do them, but this is not entirely straight forward and
it may simply not be necessary.
- Sort upgrades before other optional installs containing subsets
If I want to upgrade a package A, I schedule A3|A2|A1; if another
thing depends specifically on A1; we'd not be installed. Hence we
need to sort upgrades first.
This only is needed for optional packages; manual packages will
figure this out naturally.
- Rescoring is lazily implemented. Instead of calling make_heap()
after rescoring items, we just mark the items as dirty and reinsert
them. We also only rescore from the main solve loop, Reject() marks
the heap as needing a rescore due to a Conflict (as some versions will
no longer be installable), and RescoreWorkIfNeeded() then will do the
rescoring.
- Recursive unit propagation: Install() and Reject() recursively call
each other to promote decisions across single-version dependencies
(or across not-anymore satisfiable reverse-depends).
- Make Reason constructors explicit, this enhances readability
This makes calls like the one in here be
Reject(object, Reason(otherObject))
Ensuring that it's clear that the 2nd argument is a reason at the
caller side.
- Split Decision into Decision and Hint vs. first draft
When branching/deciding, we do not want to override SHOULD and MAY.
We do not actually use them yet, and we do actually clean them when
backtracking, but let's at least keep the data structure correct.
Convert the enum to a 16-bit integer so we can still fit in the same
space as before.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If dpkg-gencontrol was involved in the creation of a package we will not
usually encounter empty or otherwise useless fields, but apparently not
everyone is using it.
It isn't recommended to have these empty lines, but it isn't too hard to
ignore for Provides as we did for dependencies already and apt-ftparchive
can be convinced to produce empty files (if you feed it such a package)
as well, so lets be nice and provide users with a more accepting parser.
Closes: #1069874
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We schedule reverse dependencies for an upgrade, but we shouldn't do it
if we have ear-marked this package for removal later on. Usually the
solver will end up doing the right thing like it already did in the
included testcase in the end, but given that before it reaches the right
end it explored a bad path which can lead to more installs and removals
influencing later decisions or are just too hard for the resolver to
undo later on, we can just not explore this path to begin with.
References: e077370ffcb3669a50a600e80356c2002e6b176d
|
| |
|
|
|
|
| |
Ignoring errors might lead to failures later on anyhow, but especially
with triehash it could also lead to broken builds or other crazy stuff,
so lets better be save than sorry.
|
| |
|
|
|
| |
This turned out to be a bit too bold for most of them, given their
informational nature.
|
| | |
|
| |\
| |
| |
| |
| | |
UI changes for 2.9.2
See merge request apt-team/apt!343
|
| | |
| |
| |
| | |
We should pass this properly to the TagSection.write()
|
| | |
| |
| |
| |
| | |
This allows these bits to be localized, improving user experience
for users in different languages.
|
| | |
| |
| |
| |
| | |
This draws a bit more attention, and improves readability vs
keeping the color for the entire message.
|
| | |
| |
| |
| | |
Yellow is a bit odd for notices.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We never used the debug level before, so we can do that. This
allows us to have the new audit level.
We did call DumpErrors() with DEBUG in two debug code paths,
so don't touch those.
debug
|
| |/
|
|
|
| |
This will aggressively highlight out-of-compliance vs the best
practices.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All other entries in a dependency line get substantial leeway about the
amount of spaces surrounding the entry itself and its individual parts,
but the very last entry was required to have a version constraint be
at least 4 chars long (excluding opening bracket and spaces following
it), so if the version is short and a single-char relation used a space
had to make up for it. This is a bit unfair in comparison to the other
entries who do not have such unreasonable demands, so we reduce our
demand to 3 chars or longer, which is satisfied by "=1)".
If it is a good idea to hate spaces that much remains unanswered by this
commit, but in practice most tools (re)writing the files we parse will
include spaces, so its only in files (or on the satisfy command line)
directly edited by users that we can encounter such a situation, which
is a relatively new development given this line came unchanged from
the introduction of this method in 1998.
LP: #2061834
|
| |
|
|
|
| |
While this is an interactive only change that doesn't break
parsing someone got unhappy.
|
| |
|
|
|
| |
This produces a much more appealing progress bar and it can even
show parts of the progress being done.
|
| |
|
|
|
|
|
|
|
| |
Calculate an estimate of 110% of the biggest initrd + system.map
as the additional space a kernel needs in /boot.
If /boot is a different file system than /usr, print the size of
the kernels + the additional space they will need separately;
otherwise include it in our /usr figure.
|
| |
|
|
|
|
|
|
|
|
|
| |
It's interesting to the user to see the progress when it happens,
but arguably once it's done it is just visual clutter, so let's
not write newlines, and when we are done, instead of appending
"Done", let's just empty the line.
This requires some effort to keep apt-cdrom happy which just writes
lines to stdout itself. Bad apt-cdrom. Maybe there is a better fix
for it, but this gets us going.
|
| |
|
|
| |
This reverts commit 9bb953fddae0246a4dcedddb769d75d3521e1f2f.
|
| |
|
|
|
|
|
| |
The TagFile parser will have already parsed further and can't go
back so it needs to reopen the file if compressed.
Closes: #1067440
|
| |
|
|
|
|
|
|
|
| |
If we get called twice with the same offset, our d->Start and d->iOffset
will already point at the offset for the next section. But since we have
the start of the last parsed section still in the buffer, just make sure
to always go back to the start first.
Closes: #1067440
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libapt has a NotEquals relation for version constraints in
dependencies, which is used internally e.g. in the MultiArch
implementation, but this relation is not supported by Debian
policy and as such can not be used in packages.
Our parser here is extremely accepting, even unknown relations are
parsed as Equals relation – but the version that must match will be a
rather strange one…
For our own testcases and e.g. on the command line with 'satisfy' it
can make sense to have != available… and what strange things apt does
parsing unsupported relations is not really much of a concern. Real
packages will not have such relations anyhow as we are (mostly) just
a consumer, not a producer of packages and index files.
|
| |
|
|
|
|
|
|
|
|
| |
While the code claims to handle it by just continuing the loop, the
looping condition will actually cause a break from the loop failing the
interrupted writing. The non-static FileFd::Write (and ::Read) deal with
this by setting acceptable values for the loop condition as well – but
for more simplicity and consistency we can instead remove this extra loop
condition and perform the continue/break due to error handling more
explicitly.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The assertion can be overriden using apt::key::assert-pubkey-algo,
the default is the most opinionated one.
This will inform the user during apt-cdrom add as we do not
pass --quiet to user, so adjust test case.
Add a simple test case for it to test-method-gpgv.
LP: #2055193
|
| |
|
|
|
|
|
|
| |
This adds a bit more code but avoids any surprises later on by
having both the shadowed and non-shadowed meta index in the
list.
Gbp-Dch: ignore
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Convert sources.list Snapshot option from opt-in to automatic. If
we can find a snapshot server, Snapshot: yes is assumed if a snapshot
is specified.
On the implementation side, we record automatic snapshot enablement
by adding a '?' suffix to the snapshot timestamp, if any is specified,
this avoids introducing bugs into the code where we could end up with
an empty snapshot.
This has an annoying internal implementation caveat: Since we call
GetDebReleaseIndexBy() with the SHADOWED option emplaced, if we do
not find a server, we need to remove the SHADOWED option again, but
we already have inserted a shadowed release index into the list.
This will simply insert the release index a second time without the
SHADOWED option which in preliminary testing works fine, but it would
arguably be more correct to also remove the release index again if
we have created it.
FIXME: This only has one test case: A source with supported snapshot
server is auto-discovered. We should also add a test case where we
cannot detect a server and then don't fail in automatic mode.
|
| |
|
|
|
|
| |
This was automated with sed and git-clang-format, and then I had to
fix up the top of policy.cc by hand as git-clang-format accidentally
indented it by two spaces.
|
| |\
| |
| |
| |
| | |
Prevent infinite loop in `ReadConfigFile`
See merge request apt-team/apt!314
|
