Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1.exp11 2015-08-27T12:51:47Z 2015-08-27T12:51:47Z Julian Andres Klode jak@debian.org 2015-08-21T16:00:37Z urn:sha1:1c73b0fc41c23a08994ef1464c529e0aacff16de This could allow an attacker to mark a package as installed in a remote package index, as long as the package was not listed in the dpkg status file. This way, an attacker could force the installation of a package during a dist-upgrade, by providing two packages in an index, an older marked as installed, and a newer - apt would "upgrade" to the newer version. 2015-08-17T10:01:45Z Michael Vogt mvo@debian.org 2015-08-17T10:01:45Z urn:sha1:88a8975f156e452d9f3ebe76822b236e8962ebba 2015-08-10T15:27:59Z David Kalnischkies david@kalnischkies.de 2015-08-10T09:31:28Z urn:sha1:22df31be37d56c07ed029f5a4d5041f21070d2d6 Git-Dch: Ignore 2015-08-10T15:27:59Z David Kalnischkies david@kalnischkies.de 2015-07-20T11:34:25Z urn:sha1:cc480836c739e36dc0c741fa333248c0a8150ec7 We archieve the same without the special handling now, so drop this code. Makes supporting this abdomination a little longer bearable as well. Git-Dch: Ignore 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: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.