Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1.exp11 2015-08-17T12:29:02Z 2015-08-17T12:29:02Z Michael Vogt mvo@debian.org 2015-08-17T12:29:02Z urn:sha1:ac7f8f7916f16905d8eeb0133bc650d89726d0f4 Git-Dch: ignore 2015-08-17T10:01:45Z Michael Vogt mvo@debian.org 2015-08-17T10:01:45Z urn:sha1:88a8975f156e452d9f3ebe76822b236e8962ebba 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:27:58Z David Kalnischkies david@kalnischkies.de 2015-07-15T11:21:21Z urn: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 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-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. 2014-11-08T13:28:28Z David Kalnischkies david@kalnischkies.de 2014-11-07T15:45:18Z urn:sha1:765190e493645e13b5651625d87fd9c8db910a85 Git-Dch: Ignore 2014-09-26T23:45:37Z David Kalnischkies david@kalnischkies.de 2014-06-20T17:34:40Z urn:sha1:a221efc331693f8905da870141756c892911c433 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. 2014-06-18T09:17:18Z David Kalnischkies david@kalnischkies.de 2014-06-17T11:47:01Z urn:sha1:99055353a54094034c8a526aa336cd59a039676c 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. 2014-05-30T16:01:47Z David Kalnischkies david@kalnischkies.de 2014-05-30T16:01:47Z urn:sha1:1f6cf9e79742ea8e328ef2225b2f5217a9440216 Adds also a small testcase for EDSP Git-Dch: Ignore