Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_exp1 2016-05-11T08:51:06Z 2016-05-11T08:51:06Z Julian Andres Klode jak@debian.org 2016-05-11T08:51:06Z urn:sha1:5b0577488ff60e7163fe7dc62a044329d398d726 2016-05-10T20:48:31Z David Kalnischkies david@kalnischkies.de 2016-05-10T20:48:31Z urn:sha1:eb1000f6e5fa7035c764d0e7aa9ca71c7aa8d52d The spec was slightly inconsistent if the preferences setting is available only as generic or specific setting & the code only supported the specific one, while for the strict-pinning was only generic… As the usual pattern for apt is to have both options we adapt the spec and code to support both as well. This also adds a purely informal "Solver" field so in case the request is saved in a file, we know to which solver the sent preferences apply. Closes: 823918 2016-05-08T16:15:28Z David Kalnischkies david@kalnischkies.de 2016-05-08T16:03:48Z urn:sha1:39c724b4848ef8d85c8c425f982dda85f0df1277 A frontend like apt-file is only interested in a specific set of files and selects those easily via "Created-By". If it supports two locations for those files through it would need to select both and a user would need to know that implementation detail for sources.list configuration. The "Identifier" field is hence introduced which by default has the same value as "Created-By", but can be freely configured – especially it can be used to give two indexes the same identifier. 2016-05-08T11:39:32Z David Kalnischkies david@kalnischkies.de 2016-05-08T09:58:36Z urn:sha1:7f2d1eef183dbebaaabe07a296d9a97e9cfd0f4a Sometimes index files are in different locations in a repository as it is currently the case for Contents files which are per-component in Debian, but aren't in Ubuntu. This has historic reasons and is perhaps changed soon, but such cases of transitions can always happen in the future again, so we should prepare: Introduced is a new field declaring that the current item should only be downloaded if the mentioned item wasn't allowing for transitions without a flagday in clients and archives. This isn't implemented 'simpler' with multiple MetaKeys as items (could) change their descriptions and perhaps also other configuration bits with their location. 2016-05-01T08:50:24Z David Kalnischkies david@kalnischkies.de 2016-04-29T14:48:16Z urn:sha1:89901946f936446f439b95f1a9a85ac942ac2c92 Users have the option since apt >= 1.1 to enforce that a Release file is signed with specific key(s) either via keyring filename or fingerprints. This commit adds an entry with the same name and value (except that it doesn't accept filenames for obvious reasons) to the Release file so that the repository owner can set a default value for this setting effecting the *next* Release file, not the current one, which provides a functionality similar "HTTP Public Key Pinning". The pinning is in effect as long as the (then old) Release file is considered valid, but it is also ignored if the Release file has no Valid-Until at all. 2016-05-01T08:50:24Z David Kalnischkies david@kalnischkies.de 2016-04-29T08:16:42Z urn:sha1:46e00c9062d09a642973e83a334483db1f310397 A keyring file can include multiple keys, so its only fair for transitions and such to support multiple fingerprints as well. 2016-04-25T13:24:44Z Julian Andres Klode jak@debian.org 2016-04-25T13:24:02Z urn:sha1:4ad57118a8a0225b413de96dedc085e0594726a6 2016-04-05T18:24:43Z Michael Vogt mvo@ubuntu.com 2016-04-05T18:24:43Z urn:sha1:4c4b610fd029914e789caad7514ef92c6e97a327 2016-03-27T00:30:31Z Julian Andres Klode jak@debian.org 2016-03-27T00:28:12Z urn:sha1:1d4219eef6b88cb08b957378b0ca1f9762996eac 2016-03-24T18:31:51Z Julian Andres Klode jak@debian.org 2016-03-24T18:31:51Z urn:sha1:21895193b664a403179fcd8eee379b9b371084b5