Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.5_rc1 2017-01-19T14:59:38Z 2017-01-19T14:59:38Z David Kalnischkies david@kalnischkies.de 2017-01-19T14:14:19Z urn:sha1:93cff633a830e222693fc0f3d78e6e534d1126ee 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 2016-07-02T10:01:17Z David Kalnischkies david@kalnischkies.de 2016-07-02T09:28:42Z urn:sha1:0b45b6e5de1ba4224ced67a9952e009d0f4139a0 All apt versions support numeric as well as 3-character timezones just fine and its actually hard to write code which doesn't "accidently" accepts it. So why change? Documenting the Date/Valid-Until fields in the Release file is easy to do in terms of referencing the datetime format used e.g. in the Debian changelogs (policy §4.4). This format specifies only the numeric timezones through, not the nowadays obsolete 3-character ones, so in the interest of least surprise we should use the same format even through it carries a small risk of regression in other clients (which encounter repositories created with apt-ftparchive). In case it is really regressing in practice, the hidden option -o APT::FTPArchive::Release::NumericTimezone=0 can be used to go back to good old UTC as timezone. The EDSP and EIPP protocols use this 'new' format, the text interface used to communicate with the acquire methods does not for compatibility reasons even if none of our methods would be effected and I doubt any other would (in these instances the timezone is 'GMT' as that is what HTTP/1.1 requires). Note that this is only true for apt talking to methods, (libapt-based) methods talking to apt will respond with the 'new' format. It is therefore strongly adviced to support both also in method input. 2016-06-08T15:27:19Z David Kalnischkies david@kalnischkies.de 2016-06-08T11:44:29Z urn:sha1:007d8b488787f4c33ced5937f22f99f1b759088a Most (if not all) solvers should be able to run perfectly fine without root privileges as they get the entire state they are supposed to work on via stdin and do not perform any action directly, but just pass suggestions on via stdout. The new default is to run them all as _apt hence, but each solver can configure another user if it chooses/must. The security benefits are minimal at best, but it helps preventing silly mistakes (see 35f3ed061f10a25a3fb28bc988fddbb976344c4d) and that is always good. Note that our 'apt' and 'dump' solver already dropped privileges if they had them. 2016-05-20T12:18:36Z David Kalnischkies david@kalnischkies.de 2016-05-06T12:21:02Z urn:sha1:43c71fad3a51d841132ba15a7a5930e1ee4126ed This allows to differentiate properly between 'apt-get upgrade', 'apt upgrade' and 'apt full-upgrade'. 2016-05-12T14:21:10Z David Kalnischkies david@kalnischkies.de 2016-05-12T14:21:10Z urn:sha1:90e7fba4ac16fc764bf6aac7b59c17c3be551b60 Unexpected are for examples removal requests for versions which aren't installed, installations of already installed versions & requests to install and remove a package at the same time. 2016-05-12T12:52:29Z Johannes 'josch' Schauer josch@mister-muffin.de 2016-05-12T11:07:59Z urn:sha1:d67db03c2ab853eba7b67c8870af41796eea387c Document that package identifiers must be unique (apt only uses the last action for a given identifier) and that install requests do also imply upgrades and downgrades (and thus removal of the old version). This is to prevent that solvers express an upgrade or downgrade instruction as two stanzas: a removal of the old version and an installation of the new version. Instead, a single install stanza is sufficient to express upgrade or downgrade requests. 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 2015-09-14T13:22:18Z David Kalnischkies david@kalnischkies.de 2015-09-07T13:05:00Z urn:sha1:eed4639e3feea0dd4ebedfac95fb5428753b795f The syntax of "Source" is different in EDSP compared to the the field of the same name in 'the rest' of Debian, so documented this accordingly and send the version as a new field. 2014-06-18T09:17:18Z David Kalnischkies david@kalnischkies.de 2014-06-17T17:25:03Z urn:sha1:82ced5c894cd013721f432ae8da66114155e04c7 Git-Dch: Ignore 2014-06-18T09:17:18Z Stefano Zacchiroli zack@debian.org 2014-06-17T15:04:09Z urn:sha1:22c3ac52252b6eafe0d31485b18730cfb53a8dc3 Git-Dch: Ignore