Age | Commit message (Collapse) | Author |
|
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
|
|
We used to read the Release file for each Packages file and store the
data in the PackageFile struct even through potentially many Packages
(and Translation-*) files could use the same data. The point of the
exercise isn't the duplicated data through. Having the Release files as
first-class citizens in the Cache allows us to properly track their
state as well as allows us to use the information also for files which
aren't in the cache, but where we know to which Release file they
belong (Sources are an example for this).
This modifies the pkgCache structs, especially the PackagesFile struct
which depending on how libapt users access the data in these structs can
mean huge breakage or no visible change. As a single data point:
aptitude seems to be fine with this. Even if there is breakage it is
trivial to fix in a backportable way while avoiding breakage for
everyone would be a huge pain for us.
Note that not all PackageFile structs have a corresponding ReleaseFile.
In particular the dpkg/status file as well as *.deb files have not. As
these have only a Archive property need, the Component property takes
over this duty and the ReleaseFile remains zero. This is also the reason
why it isn't needed nor particularily recommended to change from
PackagesFile to ReleaseFile blindly. Sticking with the earlier is
usually the better option.
|
|
Git-Dch: Ignore
|
|
Accessing the package records to acquire this information is pretty
costly, so that information wasn't used so far in many places. The most
noticeable user by far is EDSP at the moment, but there are ideas to
change that which this commit tries to enable.
|
|
APT's cache can include packages from architectures dpkg has no
knowledge about and can therefore not be installed for e.g. to allow
easy lookups. There is no point in telling external solvers about them
though and some of them might even be really talkative about ignoring
them if we do.
|
|
Adds also a small testcase for EDSP
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.
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
- include reinstall requests and already installed (= protected) packages
in the install-request for external resolvers (Closes: #689331)
|
|
- add an IsMultiArchImplicit() method for Dep- and PrvIterator
|
|
|
|
|
|
|
|
- clean up mess with the "all" handling in MultiArch to
fix LP: #733741 cleanly for everyone now
|
|
|
|
more nicely and in order
|
|
with the text as otherwise the update will be ignored
|
|
|
|
|
|
|
|
|
|
not as PreDepends (doh!) …
|
|
to Keep which happens for example if a user decides to "remove" a not
installed package to forbid that it's part of the solution
|
|
|
|
and instead rely on the Autoremove tagging to show us what could be done.
(apt-internal-solver doesn't support this currently as it doesn't load
the auto-information into the cache)
|
|
|
|
and print the time of output at the front of the progress report
so we can see the delay
|
|
currently waiting for the solver to complete and not non-blocking
so we can generate the map while waiting for the solver
|
|
|
|
can be limited to a subset of packages with only relevant dependencies
|
|
This leads to a small performance decrease as we need to build this
mapping now while interpreting the Response but a (buggy) solver can't
point us to dangerous memory locations anymore this way and VersionCount
remains useful for other mapping proposes
|
|
|
|
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
|