apt/apt-pkg/pkgcache.cc, branch 1.1.exp11Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.1.exp112015-08-17T10:01:45ZCleanup includes after running iwyu2015-08-17T10:01:45ZMichael Vogtmvo@debian.org2015-08-17T10:01:45Zurn:sha1:88a8975f156e452d9f3ebe76822b236e8962ebbaparse packages from all architectures into the cache2015-08-10T15:27:59ZDavid Kalnischkiesdavid@kalnischkies.de2015-07-20T10:32:46Zurn:sha1:7f8c0eed6983db7b8959f1498fc8bc80c98d719e
Now that we can dynamically create dependencies and provides as needed
rather than requiring to know with which architectures we will deal
before running we can allow the listparser to parse all records rather
than skipping records of "unknown" architectures.
This can e.g. happen if a user has foreign architecture packages in his
status file without dpkg knowing about this architecture (or apt
configured in this way).
A sideeffect is that now arch:all packages are (correctly) recorded as
available from any Packages file, not just from the native one – which
has its downsides for the resolver as mixed-arch source packages can
appear in different architectures at different times, but that is the
problem of the resolver and dealing with it in the parser is at best a
hack (and also depends on a helpful repository).
Another sideeffect is that his allows :none packages to appear in
Packages files again as we don't do any kind of checks now, but given
that they aren't really supported (anymore) by anyone we can live with
that.
hide implicit deps in apt-cache again by default2015-08-10T15:27:58ZDavid Kalnischkiesdavid@kalnischkies.de2015-07-16T09:15:25Zurn:sha1:8c7af4d4c95d0423fbd0f3baa979792504f4f45f
Before MultiArch implicits weren't a thing, so they were hidden by
default by definition. Adding them for MultiArch solved many problems,
but having no reliable way of detecting which dependency (and provides)
is implicit or not causes problems everytime we want to output
dependencies without confusing our observers with unneeded
implementation details.
The really notworthy point here is actually that we keep now a better
record of how a dependency came to be so that we can later reason about
it more easily, but that is hidden so deep down in the library internals
that change is more the problems it solves than the change itself.
use a smaller type for flags storage in the cache2015-08-10T15:27:58ZDavid Kalnischkiesdavid@kalnischkies.de2015-07-15T12:36:16Zurn:sha1:dfe66c72ffc010e019e96b35154e1ad4ab506a6e
We store very few flags in the cache, so keeping storage space for 8 is
enough for all of them and still leaves a few unused bits remaining for
future extensions without wasting bytes for nothing.
Git-Dch: Ignore
remove the compatibility markers for 4.13 abi2015-08-10T15:27:58ZDavid Kalnischkiesdavid@kalnischkies.de2015-07-15T11:21:21Zurn:sha1:4dc77823d360158d6870a5710cc8c17064f1308f
We aren't and we will not be really compatible again with the previous
stable abi, so lets drop these markers (which never made it into a
released version) for good as they have outlived their intend already.
Git-Dch: Ignore
split-up Dependency struct2015-08-10T15:27:18ZDavid Kalnischkiesdavid@kalnischkies.de2015-07-13T14:28:21Zurn:sha1:71c9e95b223517b5f51c4627f6ad4cce8af0d901
Having dependency data separated from the link between version/package
and the dependency allows use to work on sharing the depdency data a bit
as it turns out that many dependencies are in fact duplicates. How many
are duplicates various heavily with the sources configured, but for a
single Debian release the ballpark is 2 duplicates for each dependency
already (e.g. libc6 counts 18410 dependencies, but only 45 unique). Add
more releases and the duplicates count only rises to get ~6 for 3
releases. For each architecture a user has configured which given the
shear number of dependencies amounts to MBs of duplication.
We can cut down on this number, but pay a heavy price for it: In my
many releases(3) + architectures(3) test we have a 10% (~ 0.5 sec)
increase in cache creationtime, but also 10% less cachesize (~ 10 MB).
Further work is needed to rip the whole benefits from this through, so
this is just the start.
Git-Dch: Ignore
bunch of micro-optimizations for depcache2015-08-10T15:27:18ZDavid Kalnischkiesdavid@kalnischkies.de2015-07-13T10:47:05Zurn:sha1:fd23676e809b7fa87ae138cc22d2c683d212950e
DepCache functions are called a lot, so if we can squeeze some drops out
of them for free we should do so. Takes also the opportunity to remove
some whitespace errors from these functions.
Git-Dch: Ignore
avoid virtual in the iterators2015-08-10T15:27:18ZDavid Kalnischkiesdavid@kalnischkies.de2015-07-13T21:10:53Zurn:sha1:3707fd4faab3f2e2521263070b68fd0afaae2900
With a bit of trickery and the Curiously recurring template pattern we
can free us from our use of virtual in the iterators were it is unneeded
bloat as we never deal with pointers to iterators and similar such.
Git-Dch: Ignore
make all d-pointer * const pointers2015-08-10T15:25:25ZDavid Kalnischkiesdavid@kalnischkies.de2015-06-17T07:29:00Zurn:sha1:6c55f07a5fa3612a5d59c61a17da5fe640eadc8b
Doing this disables the implicit copy assignment operator (among others)
which would cause hovac if used on the classes as it would just copy the
pointer, not the data the d-pointer points to. For most of the classes
we don't need a copy assignment operator anyway and in many classes it
was broken before as many contain a pointer of some sort.
Only for our Cacheset Container interfaces we define an explicit copy
assignment operator which could later be implemented to copy the data
from one d-pointer to the other if we need it.
Git-Dch: Ignore
add d-pointer, virtual destructors and de-inline de/constructors2015-06-16T14:22:46ZDavid Kalnischkiesdavid@kalnischkies.de2015-06-16T14:22:46Zurn:sha1:c8a4ce6cbed57ae108dc955d4a850f9b129a0693
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