Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.4.5 2016-07-22T14:05:09Z 2016-07-22T14:05:09Z David Kalnischkies david@kalnischkies.de 2016-07-08T13:59:23Z urn:sha1:92296fe4b0862a04ea3d965b4cd2d4a420e3be9f We support installing ./foo.deb (and ./foo.dsc for source) for a while now, but it can be a bit clunky to work with those directly if you e.g. build packages locally in a 'central' build-area. The changes files also include hashsums and can be signed, so this can also be considered an enhancement in terms of security as a user "just" has to verify the signature on the changes file then rather than checking all deb files individually in these manual installation procedures. 2015-11-04T17:04:01Z David Kalnischkies david@kalnischkies.de 2015-10-12T13:57:53Z urn:sha1:14341a7ee1ca3dbcdcdbe10ad19b947ce23d972d The main part is refactoring through to allow hiding the magic needed to support .deb files in deeper layers of libapt so that frontends have less exposure to Debian specific classes like debDebPkgFileIndex. 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:25:26Z David Kalnischkies david@kalnischkies.de 2015-06-24T20:13:51Z urn:sha1:76b580bed96aaf0174ca81ba8ed2c4b54226ad85 History suggests that this comes from an earlier apt-secure implementation, but never really became a thing, totally unused and marked as deprecated for "ages" now. Especially as it did nothing even if it would have been used (libapt itself didn't use it at all). 2015-08-10T15:25:26Z David Kalnischkies david@kalnischkies.de 2015-06-21T21:12:24Z urn:sha1:81460e32961bb0b9922bf8a1a27d87705d8c3e51 Having two different formats in the same file is very dirty and causes external tools to fail hard trying to parse them. It is probably not a good idea for them to parse them in the first place, but they do and we shouldn't break them if there is a better way. So we solve this issue for now by giving our deb822 format a new filename extension ".sources" which unsupporting applications are likely to ignore an can begin gradually moving forward rather than waiting for the unknown applications to catch up. Currently and for the forseeable future apt is going to support both with the same feature set as documented in the manpage, with the longtime plan of adopting the 'new' format as default, but that is a long way to go and might get going more from having an easier time setting options than from us pushing it explicitely. 2015-08-10T15:25:26Z David Kalnischkies david@kalnischkies.de 2015-06-21T14:47:53Z urn:sha1:463c8d801595ce5ac94d7c032264820be7434232 We support arch= for a while, now we finally add lang= as well and as a first simple way of controlling which targets to acquire also target=. This asked for a redesign of the internal API of parsing and storing information about 'deb' and 'deb-src' lines. As this API isn't visible to the outside no damage done through. Beside being a nice cleanup (= it actually does more in less lines) it also provides us with a predictable order of architectures as provides in the configuration rather than based on string sorting-order, so that now the native architecture is parsed/displayed first. Observeable e.g. in apt-get output. 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 2014-11-08T13:29:25Z David Kalnischkies david@kalnischkies.de 2014-11-07T20:26:49Z urn:sha1:0dc0b42d73ffd08bbdbe08b0678fbaae02364622 No idea what the intension was here, but it seems like a leftover from a workover which happened to be done differently later. As it doesn't provide anything at the moment we just revert to the previous abi here. Git-Dch: Ignore