apt/doc/examples, branch 1.5_rc2

show a warning for Debian shutting down FTP services

2017-07-26T17:09:04Z

We detect the effected sources by matching Release info – that has potential by-catch of repositories which have incorrect field values, but those are better fixed now anyhow. The bigger incorrectness is that this message will not only be printed for the Debian services itself but also for all mirrors not under Debian control but serving Debian like more local/private mirrors which will not (directly) shutdown. It is likely through that many of them will follow suite with less visible announcements or break downright if their upstream source disappears, so having false-positives here seems benefitial for the user in the end.

Switch from /org to /srv in example apt-ftparchive configuration

2017-07-12T21:59:39Z

/org has been obsoleted by /srv for many years on debian.org hosts.

fix various typos reported by codespell & spellintian

2017-07-08T12:55:29Z

Reported-By: codespell & spellintian Gbp-Dch: Ignore

ask for releaseinfo change interactively in apt

2017-06-28T17:18:47Z

If we have a user sitting around we can let 'apt' ask the user for a confirmation rather than print errors at the end and require the user to figure out which commandline flags are needed to confirm the changes non-interactively.

error in update on Release information changes

2017-06-28T17:18:47Z

The value of Origin, Label, Codename and co can be used in user configuration from apts own pinning to unattended upgrades. A repository changing this values can therefore have serious effects on the behaviour of apt and other tools using these values. In a first step we will generate error messages for these changes now explaining the need for explicit confirmation and provide config options and commandline flags to accept them.

Introduce Acquire::AllowTLS to turn off TLS support

2017-06-28T15:34:51Z

As requested by Henrique de Moraes Holschuh, here comes an option to disable TLS support. If the option is set to false, the internal TLS layer is disabled.

avoid explicit types for pkg counts by auto

2017-06-26T21:31:15Z

Changes nothing on the program front and as the datatypes are sufficently comparable fixes no bug either, but problems later on if we ever change the types of those and prevent us using types which are too large for the values we want to store waste (a tiny bit of) resources. Gbp-Dch: Ignore

fix various typos reported by spellintian

2017-01-19T14:59:38Z

Most of them in (old) code comments. The two instances of user visible string changes the po files of the manpages are fixed up as well. Gbp-Dch: Ignore Reported-By: spellintian

Read dpkg tables to handle architecture wildcards

2017-01-17T00:43:50Z

Our implementation of wildcards was rudimentary. It worked for some common ones, but it was also broken: For example, armel matched any-armel, but should match any-arm. With this commit, we load the correct tables from dpkg. Supported are both triplets and quadruplet tables (the latter introduced in dpkg 1.18.11). There are some odd things we have to deal with in the cache filter for historical and API reasons: * The character "*" must be accepted as an alternative to any - in fact it may appear anywhere in the wildcard as we also allow fnmatch() style wildcard matching on the commandline. * The code might get passed an arch with a minus at the end, for example the cmdline "install apt:any-arm-" will first try to check if any-arm- is a valid architecture. We deal with this by rejecting any wildcard ending in a minus. * Triplets are actually implemented by extending them to faux quadruplets - by prepending a "base" component for the architecture tuple, and "any" if there is a wildcard component. Once we have constructed a wildcard, it is transformed into an fnmatch() expression for historical reasons. In the future, we should really get a tuple class and implement matching in a better, more explicit way. This does for now though - it passes all the test cases and accepts all things it should accept. Closes: #748936 Thanks: James Clarke for the initial patch

allow warning generation for non-whitelisted options

2016-12-31T17:24:12Z

The idea is simple: Each¹ Find*( call starts with a call check if the given option (with the requested type) exists in the whitelist. The whitelist is specified via our configure-index file so that we have a better chance at keeping it current. the whitelist is loaded via a special (undocumented for now) configuration stanza and if none is loaded the empty whitelist will make it so that no warnings are shown. Much needs to be done still, but that is as good a time as any to take a snapshot of the current state and release it into the wild given that it found some bugs already and has no practical effect on users. ¹ not all in this iteration, but many