Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=master 2016-12-16T12:50:00Z 2016-12-16T12:50:00Z David Kalnischkies david@kalnischkies.de 2016-11-25T14:51:21Z urn:sha1:58ebb3017baf46e33a9bb2c1779d6daede27d108 That was the case already for tar-only and diff-only, but in a more confusing way and without a message while dsc "worked" before resulting in a dpkg-source error shortly after as tar/diff files aren't available… 2016-09-01T09:00:10Z Julian Andres Klode jak@debian.org 2016-09-01T08:57:49Z urn:sha1:0343b48e06fb990ee15a020bc6716b1a5a984e14 gpg annoyingly changed its output and broke our test suite again by adding two extra lines about key type and issuer. Really annoying. Those lines also have more than one space after the colon, so let's use \s* there - and also change the other lines to support variable length whitespace in case gpg decides to break things there too. 2015-12-19T22:04:34Z David Kalnischkies david@kalnischkies.de 2015-12-15T16:20:26Z urn:sha1:3abb6a6a1e485b3bc899b64b0a1b7dc2db25a9c2 This doesn't allow all tests to run cleanly, but it at least allows to write tests which could run successfully in such environments. Git-Dch: Ignore 2015-11-04T17:42:27Z David Kalnischkies david@kalnischkies.de 2015-10-28T13:38:49Z urn:sha1:1dd20368486820efb6ef4476ad739e967174bec4 Based on a discussion with Niels Thykier who asked for Contents-all this implements apt trying for all architecture dependent files to get a file for the architecture all, which is treated internally now as an official architecture which is always around (like native). This way arch:all data can be shared instead of duplicated for each architecture requiring the user to download the same information again and again. There is one problem however: In Debian there is already a binary-all/ Packages file, but the binary-any files still include arch:all packages, so that downloading this file now would be a waste of time, bandwidth and diskspace. We therefore need a way to decide if it makes sense to download the all file for Packages in Debian or not. The obvious answer would be a special flag in the Release file indicating this, which would need to default to 'no' and every reasonable repository would override it to 'yes' in a few years time, but the flag would be there "forever". Looking closer at a Release file we see the field "Architectures", which doesn't include 'all' at the moment. With the idea outlined above that 'all' is a "proper" architecture now, we interpret this field as being authoritative in declaring which architectures are supported by this repository. If it says 'all', apt will try to get all, if not it will be skipped. This gives us another interesting feature: If I configure a source to download armel and mips, but it declares it supports only armel apt will now print a notice saying as much. Previously this was a very cryptic failure. If on the other hand the repository supports mips, too, but for some reason doesn't ship mips packages at the moment, this 'missing' file is silently ignored (= that is the same as the repository including an empty file). The Architectures field isn't mandatory through, so if it isn't there, we assume that every architecture is supported by this repository, which skips the arch:all if not listed in the release file. 2015-08-12T09:55:47Z Luca Bruno lethalman88@gmail.com 2015-08-11T18:08:43Z urn:sha1:94171725b18be91ddcc2530c5fe5f40e78d041c1 Thanks: Andre Felipe Machado for initial patch Closes: 414848 2015-06-15T21:35:55Z David Kalnischkies david@kalnischkies.de 2015-06-15T14:41:43Z urn:sha1:1eb1836f4b5397497bd34f0cf516e6e4e73117bf Again, consistency is the main sellingpoint here, but this way it is now also easier to explain that some files move through different stages and lines are printed for them hence multiple times: That is a bit hard to believe if the number is changing all the time, but now that it keeps consistent. 2015-06-15T21:35:54Z David Kalnischkies david@kalnischkies.de 2015-06-15T11:36:11Z urn:sha1:ff86d7df6a53ff6283de4b9a858c1dad98ed887f All other methods call it, so they should follow along even if the work they do afterwards is hardly breathtaking and usually results in a URIDone pretty soon, but the acquire system tells the individual item about this via a virtual method call, so even through none of our existing items contains any critical code in these, maybe one day they might. Consistency at least once… Which is also why this has a good sideeffect: file: and cdrom: requests appear now in the 'apt-get update' output. Finally - it never made sense to hide them for me. Okay, I guess it made before the new hit behavior, but now that you can actually see the difference in an update it makes sense to see if a file: repository changed or not as well. 2015-04-18T23:13:09Z David Kalnischkies david@kalnischkies.de 2015-04-11T18:13:19Z urn:sha1:d84da4995df24329e96d57a22136683a9e370f4e Its a bit unpredictable which permissons and owners we will encounter on a CD-ROM (or a USB stick, as apt-cdrom is responsible for those too), so we have to ensure in this codepath as well that everything is nicely setup without waiting for a 'apt-get update' to fix up the (potential) mess. 2015-03-16T17:01:54Z David Kalnischkies david@kalnischkies.de 2015-03-09T23:59:44Z urn:sha1:25b86db159fbc3c043628e285c0c1ef24dec2c6e We use test{success,failure} now all over the place in the framework, so its only consequencial to do this in the situations in which we test for a specific output as well. Git-Dch: Ignore 2014-11-18T01:41:20Z David Kalnischkies david@kalnischkies.de 2014-11-17T21:54:29Z urn:sha1:4bb006d1ddcf1807474067dcbef9fb0bb5def0ac While on linux files are created in /tmp with $USER:$USER, on my kfreebsd testmachine they are created with $USER:root, so we pull some strings here to make it work on both.