| Age | Commit message (Collapse) | Author |
|---|
|
A rather special need option, but the internal planer supports this and
we have a testcase for it & sometimes it is hit (as a bug through). The
option itself mostly serves as a reminder for implementors that they
should be careful with removes and especially temporary removes if they
perform any.
|
|
APT has 3 modes: no immediate configuration, all packages are configured
immediately and its default mode of configuring essentials and
pseudo-essentials immediately only. While this seems like a job of
different planers at first, it might be handy to have it as an option,
too, in case a planer (like apts internal one) supports different modes
where the introduction of individual planers would be counter intuitive.
|
|
Testing the current implementation can benefit from being able to be
feed an EIPP request and produce a fully compliant response. It is also
a great test for EIPP in general.
|
|
The very first step in introducing the "external installation planer
protocol" (short: EIPP) as part of my GSoC2016 project.
The description reads: APT-based tools like apt-get, aptitude, synaptic,
… work with the user to figure out how their system should look like
after they are done installing/removing packages and their dependencies.
The actual installation/removal of packages is done by dpkg with the
constrain that dependencies must be fulfilled at any point in time (e.g.
to run maintainer scripts).
Historically APT has a super micro-management approach to this task
which hasn't aged that well over the years mostly ignoring changes in
dpkg and growing into an unmaintainable mess hardly anyone can debug and
everyone fears to touch – especially as more and more requirements are
tacked onto it like handling cycles and triggers, dealing with
"important" packages first, package sources on removable media, touch
minimal groups to be able to interrupt the process if needed (e.g.
unattended-upgrades) which not only sky-rocket complexity but also can
be mutually exclusive as you e.g. can't have minimal groups and minimal
trigger executions at the same time.
|
|
|
|
EDSP had a WriteSolution method to write out the entire solution based
on the inspection of a given pkgDepCache, but that is rather inflexible
both for EDSP itself and for other EDSP like-protocols. It seems better
to use a smaller scope in printing just a single stanza based on a given
version as there is more reuse potential.
|
|
Its more space and runtime efficient to use a boolean set instead of a
CacheSet-based implementation.
Git-Dch: Ignore
|
|
This allows to differentiate properly between 'apt-get upgrade', 'apt
upgrade' and 'apt full-upgrade'.
|
|
I doubt there is any non-src:apt usage of these interfaces.
|
|
Git-Dch: Ignore
|
|
More warnings are always better.
Git-Dch: Ignore
|
|
To have a chance to keep the ABI for a while we need all three to team
up. One of them missing and we might loose, so ensuring that they are
available is a very tedious but needed task once in a while.
Git-Dch: Ignore
|
|
Solvers are supposed to exit successfully even if they haven't found a
solution, but a solver which fails drastically (like e.g. segfaults)
should be detected and dealt with accordingly instead of ignored.
|
|
This methods should not be used by anyone expect the library itself as
they are helpers for the specific class and therefore perfect candidates
for hidding.
Git-Dch: Ignore
|
|
Beside being a bit cleaner it hopefully also resolves oddball problems
I have with high levels of parallel jobs.
Git-Dch: Ignore
Reported-By: iwyu (include-what-you-use)
|
|
Reported-By: gcc -Wunused-parameter
Git-Dch: Ignore
|
|
|
|
The breakage is just to big for now, so guard the change with
#ifndef APT_8_CLEANER_HEADERS and be nice to library users
|
|
- make the cachesets real containers which can embedding any container
to be able to use the same interface regardless of set or list usage
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
can be limited to a subset of packages with only relevant dependencies
|
|
The solution is NOT interpreted so far.
|
|
|
|
|
|
|
|
just writing stuff… it also reads and can work for both:
- APT talking to an external solver
- an external solver (understanding EDSP) talking to APT
|
