apt/apt-pkg/pkgcachegen.h, branch 1.1.10Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.1.102015-12-29T15:29:05ZpkgCacheGenerator: Allow passing down an already created cache2015-12-29T15:29:05ZJulian Andres Klodejak@debian.org2015-12-29T14:59:41Zurn:sha1:f161603953f92cc3e778439d7149e5b852f65277
If we already have opened a cache, there is no point in having
to open it again.
pkgcachegen.h: Hack around unordered_map not existing before C++112015-12-27T15:43:28ZJulian Andres Klodejak@debian.org2015-12-27T15:43:28Zurn:sha1:2837a71877c0f5c1aca8f70e30130018bc53acac
This is for public users only, which cannot use the class at all,
except for the static methods.
pkgcachegen: Use std::unordered_map instead of std::map2015-12-27T00:46:06ZJulian Andres Klodejak@debian.org2015-12-27T00:33:38Zurn:sha1:e9185eca390435b4060ef26c7c69d39f994da7a7
std::unordered_map is faster than std::map in our use case,
reducing cache generation time by about 10% in my benchmark.
add messages to our deprecation warnings in libapt2015-11-27T14:40:47ZDavid Kalnischkiesdavid@kalnischkies.de2015-11-27T14:40:47Zurn:sha1:5dd00edbcf702cac1ea22392796c65881a8ef6f9
Git-Dch: Ignore
Drop C++11 elements from headers2015-08-11T11:59:15ZJulian Andres Klodejak@debian.org2015-08-11T09:49:21Zurn:sha1:350d30d24fee9a1aa5fedc7a30e7416999653417eliminate dead file-provides code in cache generation2015-08-10T15:27:59ZDavid Kalnischkiesdavid@kalnischkies.de2015-07-20T08:33:07Zurn:sha1:1d3eea5caf65aacd7f112d14030a0499f32b9c75
The code was never active in production, it just sits there collecting
dust and given that it is never tested probably doesn't even work
anymore the way it was supposed to be (whatever that was exactly in the
first place). So just remove it before I have to "fix" it again next
time.
Git-Dch: Ignore
elimate duplicated code in pkgIndexFile subclasses2015-08-10T15:27:59ZDavid Kalnischkiesdavid@kalnischkies.de2015-07-20T08:17:29Zurn:sha1:c9443c01208377f0cba9706412ea3a98ad97b56d
Trade deduplication of code for a bunch of new virtuals, so it is
actually visible how the different indexes behave cleaning up the
interface at large in the process.
Git-Dch: Ignore
add volatile sources support in libapt-pkg2015-08-10T15:27:59ZDavid Kalnischkiesdavid@kalnischkies.de2015-07-18T16:03:54Zurn:sha1:5465192b9aeb1ccea778950ccf2d1b7b32f2cd91
Sources are usually defined in sources.list (and co) and are pretty
stable, but once in a while a frontend might want to add an additional
"source" like a local .deb file to install this package (No support for
'real' sources being added this way as this is a multistep process).
We had a hack in place to allow apt-get and apt to pull this of for a
short while now, but other frontends are either left in the cold by this
and/or the code for it looks dirty with FIXMEs plastering it and has on
top of this also some problems (like including these 'volatile' sources
in the srcpkgcache.bin file).
So the biggest part in this commit is actually the rewrite of the cache
generation as it is now potentially a three step process. The biggest
problem with adding support now through is that this makes a bunch of
previously mostly unusable by externs and therefore hidden classes
public, so a bit of further tuneing on this now public API is in order…
just-in-time creation for (explicit) negative deps2015-08-10T15:27:59ZDavid Kalnischkiesdavid@kalnischkies.de2015-07-17T08:53:01Zurn:sha1:bb0f6a34c4cebea7884de828c011dc85765ff820
Now that we deal with provides in a more dynamic fashion the last
remaining problem is explicit dependencies like 'Conflicts: foo' which
have to apply to all architectures, but creating them all at the same
time requires us to know all architectures ending up in the cache which
isn't needed to be the same set as all foreign architectures.
The effect is visible already now through as this prevents the creation
of a bunch of virtual packages for arch:all packages and as such also
many dependencies, just not very visible if you don't look at the stats…
Git-Dch Ignore
just-in-time creation for (implicit) Provides2015-08-10T15:27:59ZDavid Kalnischkiesdavid@kalnischkies.de2015-07-16T17:41:45Zurn:sha1:ecc138f858fab61e0b888d3d13854d1422c3432b
Expecting the worst is easy to code, but has its disadvantages e.g.
by creating package structures which otherwise would have never
existed. By creating the provides instead at the time a package
structure is added we are well prepared for the introduction of partial
architectures, massive amounts of M-A:foreign (and :allowed) and co as
far as provides are concerned at least. We have something relatively
similar for dependencies already.
Many tests are added for both M-A states and the code cleaned to
properly support implicit provides for foreign architectures and
architectures we 'just' happen to parse.
Git-Dch: Ignore