Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1.exp11 2015-08-17T10:01:45Z 2015-08-17T10:01:45Z Michael Vogt mvo@debian.org 2015-08-17T10:01:45Z urn:sha1:88a8975f156e452d9f3ebe76822b236e8962ebba 2015-08-11T13:58:42Z Julian Andres Klode jak@debian.org 2015-08-11T13:58:03Z urn:sha1:6d7122b5356c0b4d8f51aafdfc1c232392fca695 Gbp-Dch: ignore Reported-By: g++ -Wsuggest-override Thanks: g++ -Wsuggest-override 2015-08-10T15:27:59Z David Kalnischkies david@kalnischkies.de 2015-07-20T10:32:46Z urn: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. 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:17Z David Kalnischkies david@kalnischkies.de 2015-07-08T22:35:40Z urn:sha1:3b3028467ceccca0b73a8f53051c0fa4de313111 C++11 adds the 'override' specifier to mark that a method is overriding a base class method and error out if not. We hide it in the APT_OVERRIDE macro to ensure that we keep compiling in pre-c++11 standards. Reported-By: clang-modernize -add-override -override-macros Git-Dch: Ignore 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-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 2015-06-15T12:39:37Z David Kalnischkies david@kalnischkies.de 2015-06-12T12:42:17Z urn:sha1:e185d8b3e39e3840f439cab7d5d265fd96d84c6f This is mainly visible in the policy, so that you can now pin by b= and let it only effect Packages files of this architecture and hence the packages coming from it (which do not need to be from this architecture, but very likely are in a normal repository setup). If you should pin by architecture in this way is a different question… Closes: 687255 2015-06-12T14:33:37Z David Kalnischkies david@kalnischkies.de 2015-06-12T00:08:53Z urn:sha1:b07aeb1a6e24825e534167a737043441e871de9f 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.