Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1.exp11 2015-08-11T11:59:15Z 2015-08-11T11:59:15Z Julian Andres Klode jak@debian.org 2015-08-11T09:49:21Z urn:sha1:350d30d24fee9a1aa5fedc7a30e7416999653417 2015-08-10T15:27:59Z David Kalnischkies david@kalnischkies.de 2015-07-20T08:33:07Z urn: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 2015-08-10T15:27:59Z David Kalnischkies david@kalnischkies.de 2015-07-20T08:17:29Z urn: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 2015-08-10T15:27:59Z David Kalnischkies david@kalnischkies.de 2015-07-18T16:03:54Z urn: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… 2015-08-10T15:27:59Z David Kalnischkies david@kalnischkies.de 2015-07-17T08:53:01Z urn: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 2015-08-10T15:27:59Z David Kalnischkies david@kalnischkies.de 2015-07-16T17:41:45Z urn: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 2015-08-10T15:27:58Z David Kalnischkies david@kalnischkies.de 2015-07-16T09:15:25Z urn: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. 2015-08-10T15:25:25Z David Kalnischkies david@kalnischkies.de 2015-06-17T07:29:00Z urn: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 2015-08-10T15:24:01Z David Kalnischkies david@kalnischkies.de 2015-06-16T22:14:10Z urn:sha1:e8afd16892e87a6e2f17c1019ee455f5583387c2 Some of them modify the ABI, but given that we prepare a big one already, these few hardly count for much. Git-Dch: Ignore 2015-06-16T14:22:46Z David Kalnischkies david@kalnischkies.de 2015-06-16T14:22:46Z urn: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