Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1_exp15 2015-11-05T11:21:33Z 2015-11-05T11:21:33Z David Kalnischkies david@kalnischkies.de 2015-11-05T00:51:44Z urn:sha1:f01f5d911d6a9731893865bb1ec617c5038add3e This 'ignores' the component Release files you can find in Debian alongside the binary-* directories, which isn't exactly a common usecase, but it worked before, so lets support it again as this isn't worse than a valid Release file which is unsigned. Git-Dch: Ignore 2015-11-05T11:21:33Z David Kalnischkies david@kalnischkies.de 2015-11-04T22:38:40Z urn:sha1:4453cfdcf42f7fe6859bb0fc6b310a2a391bee77 Limit the field length to a char to avoid bogus FF for utf-8 characters with the default length. Closes: 799123 2015-11-05T11:21:33Z David Kalnischkies david@kalnischkies.de 2015-11-04T20:08:55Z urn:sha1:258b9e512c4001e806c5c0966acecd3d742ec6e9 Reported-By: cppcheck Git-Dch: Ignore 2015-11-05T11:21:33Z David Kalnischkies david@kalnischkies.de 2015-11-04T13:48:36Z urn:sha1:23e64f6d0facf9610c1042326ad9850e071e8349 Allows users who know what they are getting themselves into with this trick to e.g. disable privilege dropping for e.g. file:// until they can fix up the permissions on those repositories. It helps also the test framework and people with a similar setup (= me) to run in less modified environments. 2015-11-05T11:21:33Z David Kalnischkies david@kalnischkies.de 2015-11-04T12:19:14Z urn:sha1:30c8107e9c56d7d78dcf9136f94aeed9d631dfb3 Continueing on the track of dropping privileges in all methods, lets drop it in copy, too, as the reasoning for it is very similar to file and the interaction between the too quiet interesting as copy kinda surfed as a fallback for file not being able to read the file. Both now show a better error message as well as it was previously claiming to have a hashsum mismatch, given that it couldn't read the file. Git-Dch: Ignore 2015-11-04T17:42:28Z David Kalnischkies david@kalnischkies.de 2015-11-03T15:05:14Z urn:sha1:23d35ec15a849ee755f51a99939b0131e8faefa5 This flags is generally handy to avoid having to deal with ipv6 results on an ipv4-only system, but it prevents e.g. the testcases from working if the testsystem has no configured address at the moment (expect loopback), so allow it to be sidestepped and let the testcases sidestep it. Git-Dch: Ignore 2015-11-04T17:42:28Z David Kalnischkies david@kalnischkies.de 2015-11-02T15:02:44Z urn:sha1:cd46d4ebd33e74ee53bbc73dcdb7fe1d4d006558 The wrapping will fail in the best case and actually end up deleting /dev/null in the worst case. Given that there is no point in trying to write atomically to /dev/null as you can't read from it again just ignore these flags if higher level code ends up trying to use them on /dev/null. Git-Dch: Ignore 2015-11-04T17:42:28Z David Kalnischkies david@kalnischkies.de 2015-10-30T22:16:01Z urn:sha1:2f91076de326a0dee067659381a9c4cf745f0efe Leading or trailing newlines can be confusing for our parser as it expects two newlines to start/stop a new stanza. To solve this the lines we wanna add are printed first, ignore any leading newlines and then add the stanza as provided by dpkg-deb with or without trailing newlines as the parser will look at the first stanza only anyway and removing trailing newlines is considerably harder to do. Closes: 802553 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-11-04T17:04:05Z David Kalnischkies david@kalnischkies.de 2015-10-30T15:34:25Z urn:sha1:294a80209a0c6ea617a14fb2ae650d4fd329eab5 This was discussed a while ago on #debian-apt and now that I see myself making this mistake lets bite the bullet and fix it in the easy way out version: Using a new name which fits with a similar named setter and deprecate the old method instead of 'hostily' changing API. Closes: #803471